Page 1 of 1


Posted: 17 Mar 2009, 23:07
by Robbe
Hi there,

I'm wondering if the synchronization-objects in Poco (especially Semaphore, Mutex and RWLock) resume the threads waiting on it in FIFO order (like explicitly stated on the docs of Condition). If this wouldn't be the case, it is probably possible to have starvation when RWLock is used and there are more readlocks invoked then writelocks, or am I all wrong here?
Also, when I tested the use of RWLock, I managed it to make it throw an exception that said "Unable to retrieve lock" (but not always, hence I thought that it was a threading issue, but this seems odd as RWLock is made for use in threading). (Note that I explicitly used writeLock and readLock and not tryWriteLock and tryReadLock, but I've thrown away the exact code appearantly.) Can anyone say why this could have happened?


Re: Starvation

Posted: 24 Mar 2009, 10:50
by guenter
Mutex is only a small wrapper over the respective platform's mutex primitive (pthread_mutex on POSIX systems, CRITICAL_SECTION on Windows), so there should not be any starvation issues.
Semaphore is implemented using the Windows Semaphore primitive on Windows, and using pthread_cond on POSIX, so no issues there as well.
RWLock is mapped to pthread_rwlock on POSIX systems, so no issues there provided your pthreads implementation does things right. On Windows, RWLock is implemented using Windows Mutex and Event objects, and it prioritizes Writers over Readers - as soon as on writer waits, no more readers will be granted access. Having said that, and given the difficulty getting synchronization primitives right, there might be something lurking in the Windows implementation of RWLock. Maybe someone could review the code?

Re: Starvation

Posted: 25 Mar 2009, 23:33
by Robbe
Thanks for the explanation!

In the mean time we stopped using the RWLock because the way we used it was code smell,
but nevertheless, thanks again.