Hi Przemyslaw, Przemyslaw Czerpak wrote: > Thanks though it will not help us very much. > It's necessary to change the OS2 code to eliminate possible race condition. > BTW I see in xHarbour that you used together: > DosPostEventSem( hSem ); > DosResetEventSem( hSem, &ulCount ); > so I guess that it's guarantied that all threads blocked on hSem by > DosWaitEventSem() will be woken up even if other thread immediately > calls DosResetEventSem() before any of this thread begin execution.
I think this is what happens, even if I never made such a test, anyway OS/2 sdk states that: ---------------8<--------------------- DosResetEventSem resets an event semaphore if it is not already reset, and returns the number of times the semaphore was posted since it was last reset. All threads that subsequently call DosWaitEventSem for this semaphore will be blocked. Any thread belonging to the process that created the event semaphore can change the state of the semaphore to reset by calling DosResetEventSem. Threads in other processes can also call DosResetEventSem, but they must first gain access to the semaphore by calling DosOpenEventSem. When an event semaphore is in the reset state, any thread that calls DosWaitEventSem to wait for the semaphore will be blocked. When the event semaphore is posted, all of the threads that are waiting for the semaphore are released to continue execution. --------------->8--------------------- > Without such condition the above peace of code may never wake up all > threads. But there is other problem and as I can see it exists also > in xHarbour. It's still possible that signal will be lost and waiting > thread will never be woken up due to hb_threadCondWait() implementation. > It needs multistate semaphore like in Windows to be sure that we do not > lost posted event. > F.e. 1-st thread is waiting on some results calculated by 2-nd thread > in code like: > > hb_threadEnterCriticalSection( mutex ); > while( result == 0 ) > hb_threadCondWait( cond, mutex ); > hb_threadLeaveCriticalSection( mutex ); > > The second thread is making: > hb_threadEnterCriticalSection( mutex ); > result += nDone; > hb_threadLeaveCriticalSection( mutex ); > hb_threadCondSignal( cond ); > > in hb_threadCondWait() the mutex should be unlocked and process suspended > in one atomic operation. OS2 API does not give us such functionality and > the code like above can freeze 1-st thread forever. It may happen if > inside hb_threadCondWait() it executes: > DosReleaseMutexSem( mutex ); > and OS suspend the thread before executing: > DosWaitEventSem( cond ); > activating 2-nd thread. Which can lock unlocked mutex set result and > send signal which will be ignored because the 1-st thread has not > entered DosWaitEventSem() yet. The second thread finish its job and > terminates and the 1-st one is never woken up so our application > hangups. The above now can happen in xHarbour. I see these two comments on OS/2 sdk: -------------------8<----------------- If the semaphore is already posted when DosWaitEventSem is called, the function returns immediately, and the thread continues to run. Otherwise, the thread is blocked until the semaphore is posted. ------------------->8----------------- and also -------------------8<----------------- Unlike multiple event semaphores in a muxwait list, which are level-triggered, single event semaphores are edge-triggered. This means that if an event semaphore is posted and then reset before a waiting thread gets a chance to run, the semaphore is considered to be posted for the rest of that thread's waiting period; the thread does not have to wait for the semaphore to be posted again. ------------------->8----------------- So the thread should not block and the event does not get lost. Do you think this answers your questions? Best regards. Maurilio. -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
