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>:
> Le samedi 25 juillet 2009 20:11:34 Carlos O'Donell, vous avez écrit :
>> > 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()).
>
> That's not what I understand from POSIX neither from the glibc source code.
> If I'm reading glibc source code right, it's just waiting for SIGTIMER. When
> it occurs, it takes a global lock, creates a thread, releases the lock. It is
> nowhere waiting for the created thread to finish before it tries to create a
> new one. So in my understanding, especially with a very short interval, the
> timer function could be running in more than one thread at a time for the same
> timer ID.

There are several cases here.

Can you guarantee your application runs only using NPTL pthreads?

If that is the case then you only have two cases to consider.

The case where the kernel implements timer_create and the case where
that syscall is not available.

The case you describe is the later, userspace uses a normal timer to
emulate SIGEV_THREAD. In this case timer_delete unlinks the timer from
the timer list, the unlink operation is atomic and timer_delete holds
the __timer_mutex. The previous conditions IMO would guarantee that
calling timer_delete makes sure that nothing else will run after that
call.

The complicated case is where timer_create is implemented by the
kernel, and userspace has no ability to intercept a signal or use
locks to synchronize. You will have to see what the kernel does in the
case of timer_delete, does it dequeue all pending thread creations?

Cheers,
Carlos.


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