This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cleaning up after timer_delete


2009/7/25 Rémi Denis-Courmont <remi@remlab.net>:
> In my understanding, foo_stop() is buggy. If the user pressed enter while
> foo_timer() is running, foo_timer() will end up reading memory that was free'd
> by foo_stop(). This can happen because timer_delete() does NOT warranty that
> pending occurences of the timer have been completed.
>
> I'm wondering how to use interval timers from a library such that I can safely
> clean up data after the timer is disarmed.

Disarm the timer from the event thread, which AFAICT should assure you
that no other events are possible, only one event may be executing at
a given moment (overruns are reported via timer_getoverrun()).

e.g.
* In foo_stop set the stop flag.
* In foo_timer check the flag, if set delete the timer, clear the
flag, and return.
* In foo_stop continue waiting for flag to clear, and once clear
deallocate the resources.

Where the flag can be anything from an atomic bitset operation or a
pthread primitive.

POSIX only says that it is implementation defined to call timer_create
with a clock id created in another thread or process, but says nothing
about timer_delete.

You might want to try write a testcase that tries to trigger the race
condition and set it to run on an SMP system for several days.
However, I think the above suggestion should work.

Cheres,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]