Matthew Kirkwood wrote:
>
> On Tue, 12 Mar 2002, Bruce Momjian wrote:
>
> > > They're basically the same thing. Currently, pthread_mutexes on Linux
> > > (implemented in glibc) are fairly gross in the contended case, since
> > > there is no clean way to wait for lock release,
>
> > Strange that it doesn't wait for the lock.
> [..]
>
> It does wait, in that the call will not return before or unless
> the thread has acquired the lock. However, it waits in an ugly
> way, via spin-and-yield or some evil signal or pipe hackery via
> a manager thread.
>
> pthread_mutexes are fairly ugly, but they should still be
> lightweight. Until now, there was no way to do that under
> Linux. (I don't know how the other free Unixes do it, but I
> suspect it is not much better.)
If all free Unixes do it in such an ugly way then well, what you get is
what you paid for ;)
I still would be surprized if all implementations were as bad as Linux
one is. Pthread mutexes are very lightweight and fast on Solaris and QNX
(I mostly work with those). They can be shared across processes on both.
Implementation-wise, QNX has corresponding blocking state so when some
thread locks a mutex other contenders get blocked by kernel. They are
(one of them) unblocked by kernel when mutex is released.
Speaking about ugliness, the only issue I see with pthread mutexes is
that they can get orphaned. There is no portable way to deal with that,
but again both Solaris and QNX have extended API which allows some
thread to aqcuire ownership of an orphaned mutex. I guess that
eventually will make its way into POSIX.
-- igor
