This is the mail archive of the
pthreads-win32@sourceware.org
mailing list for the pthreas-win32 project.
Re: Pthread-win32 races?
Hello.
The library is working correctly since sem_destroy() is returning the
error EBUSY as required and documented at:
http://sourceware.org/pthreads-win32/manual/sem_init.html
This is also in accordance with the Single Unix Specification. If it was
hanging your program rather than returning the error then that would be
a problem.
The sem_destroy function sets errno to the following error code on error:
EBUSY if some threads are currently blocked waiting on the semaphore.
But there's obviously no threads waiting on semaphore, is there?
By the way, in your sample code you don't check the return code from the
sem_post(), but the semaphore could already be destroyed at that point.
It couldn't (shouldn't, because actually it does). Because semaphore
is destroyed only after sem_wait(), but sem_wait() returns (should
return) only after sem_post() succeeds. Did I understood right?
It would be better in this and similar cases to call sem_destroy() after
the call to pthread_join(), or at least after you can guarantee that the
semaphore is no longer required by any child threads.
In this example I can destroy semaphore after pthread_join(). But in
my program logic is more complicated and sem_post()'ing thread doesn't
finish after sem_post(). And again the same question: Does sem_post()
perform atomic access to the semaphore or I should perform additional
synchronisation to access the semaphore? Synchronizing access to
semaphore looks strange, don't you think so?
This quotation is from linux sem_post manual:
!sem_post! atomically increases the count of the semaphore pointed to
by |sem|. This function never blocks and can safely be used in asyn-
chronous signal handlers.
So, I think supplied code must be correct according to manual.
A sem_t "handle" is not required to be unique in time, so it's possible
to destroy a semaphore and init a new one having another purpose
altogether, which then by chance occupies the same physical memory
location, i.e. has the same "handle" (in pthreads-win32 this is just the
pointer to the struct in memory), so a sema op somewhere may not fail
even though, logically, it is no longer accessing the semaphore it
should be, and the application may now be mysteriously badly behaved and
difficult to debug.
Yes, I understand this. And there's no chance to accidentally access
destroyed semaphore.
--
eof