On Mon, 16 Feb 2009, Maurilio Longo wrote:
Hi Maurilio,
> You're correct, this comes from OS/2 docs:
[...]
Thanks for information.
> > 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.
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.
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.
Multistate semaphores like in Windows resolve this problem (though they
are not such elegant and efficient like pure PTHREAD API) but I cannot
find anything like that in OS2 API so we will have to resolve the problem
in different way.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
