Przemyslaw Czerpak wrote: > Looks that I haven't read OS2 API documentation carefully. > Thanks for fix. > Though I have few questions because looks that current code have to > be updated. Your modification suggests that DosPostEventSem() sends > broadcast message and wake up _ALL_ threads which where blocked by > event semaphore by DosWaitEventSem() and not only one. DosWaitEventSem() > blocks calling thread on event semaphore only if this semaphore was > not posted after last call to DosResetEventSem() so it's necessary to > call DosResetEventSem() to clear all posted events and make event semaphore > blocking. I guess that DosResetEventSem() is atomic operation and when > two or more threads call this function simultaneously then only one will > receive non 0 value if semaphore was posted.
You're correct, this comes from OS/2 docs: -------------8<------------------- An event semaphore provides a signaling mechanism among threads or processes, ensuring that events occur in the desired sequence. Event semaphores are used by one thread to signal other threads that an event has occurred. An application can use this type of semaphore to block a thread or process until the event has occurred. An event semaphore has two states, reset and posted. When an event semaphore is in the reset state, OS/2 blocks any thread or process that is waiting on the semaphore. When an event semaphore is in the posted state, all threads or processes waiting on the semaphore resume execution. For example, assume thread 1 is allocating a shared memory object and threads 2 and 3 must wait for the memory to be allocated before they attempt to examine its contents. Before thread 1 allocates the memory, it creates an event semaphore, specifying the initial state of the semaphore as reset. (If the event semaphore has already been created, thread 1 simply resets the semaphore.) Threads 2 and 3 use DosWaitEventSem to wait for the semaphore to signal that the event, in this case the allocation and preparation of the shared memory object, has been completed. Because the semaphore was reset by thread 1, threads 2 and 3 are blocked when they call DosWaitEventSem. After thread 1 has finished allocating and placing data in the shared memory object, it signals the completion of its task by posting the event semaphore. The posting of the event semaphore unblocks threads 2 and 3, enabling them to resume execution. They can then proceed to examine the contents of the allocated memory. In the example above, one thread controls the resetting and posting of the event semaphore, while other threads merely wait on the semaphore. Another approach could be for an application or thread to reset an event semaphore, then block itself on that semaphore. At a later time, another application or thread would post the event semaphore, unblocking the first thread. ------------->8------------------- > If I'm right then I see few potential problems. > 1-st we do not need separate macros for HB_COND_SIGNAL() and > HB_COND_SIGNALN() in OS2 builds because all works like HB_COND_BROADCAST() > and wake up all waiting threads. Yes > 2-nd we should change all places where HB_COND_TIMEDWAIT() is used > and check timeout parameter ourselves just like in hb_threadWait() > function. In summary I should implement it at beginning because it > pacifies also other potential though minor problem on MS-Win builds. > But there is also other problem much more critical. DosResetEventSem() > is not atomic to DosWaitEventSem() and we have nothing to sync well > number of posted signals with number of waiting threads to be sure > that all threads will be woken up. To resolve this problem we have You can call DosQueryEventSem() to know how many times a semaphore has been posted since last DosResetEventSem() which gives you back this info when called. -------------8<------------- DosResetEventSem resets an event semaphore, causing all threads that subsequently call DosWaitEventSem to be blocked. It also returns the post count for the semaphore. The post count is the number of times that DosPostEventSem has been called since the last time the semaphore was in the reset state. ------------->8------------- > to move DosResetEventSem() changing the code in OS2 builds. But > before I'll make deeper modifications I would like to confirm that > I correctly described how DosWaitEventSem(), DosPostEventSem() and > DosResetEventSem() work. I do not have precise OS2 documentation > and I have to guess some things. > You're correct. Thanks a lot. Maurilio. > best regards, > Przemek > _______________________________________________ > Harbour mailing list > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
