This is the mail archive of the pthreads-win32@sourceware.org mailing list for the pthreas-win32 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: Pthread-win32 races?


Sergey Fokin wrote:
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?
My apologies - I didn't even see the sem_wait() even though it's right before the sem_destroy(), and regardless, as you say, it should only return EBUSY if someone is waiting, not posting. It's been a while but the code looks like it tries to ensure this. I'll have to look closer when I'm more awake.

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?
As above - my mistake.

Ross


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