Subj : Re: pthread_cond_signal() semantics
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Mon Jan 10 2005 10:20 am

Marcin 'Qrczak' Kowalczyk wrote:

> Giancarlo Niccolai <searchforme@ingoogle.com> writes:
> 
>> I am talking against implementations that wake up waiting threads as
>> soon as the mutex they are waiting for is freed.
> 
> Ah, then ok, my implementation of threads for Kogut doesn't yield the
> processor on unlocking a mutex.
> 
Mutexes in scripting languages are not "minimal" mutexes in any case: a
single VM loop is usually bigger than the minimal set of instructions you
want to lock with a pthread like mutex; so they anyhow follow different
rules.

I.e. in xharbour (clipper clone), I had to implement mutexes as condition
waits. The fact that a thread may be interrupted at any  VM loop and the
fact that a VM loop spans 7000 c lines (!) with several deep calls with
possible cancellation points forced me to have objects that can be
controlled used as mutexes, and machine level/posix level mutexes cannot...
so take good care for your kogurt!

Gian.

.