|
Home > Archive > Unix Programming > June 2005 > Solaris adaptive mutex in userland?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Solaris adaptive mutex in userland?
|
|
| Frank Cusack 2005-06-22, 2:50 am |
| Are Solaris adaptive mutexes available to userland programs? If so,
how does one use them? Preferably there is a pthreads interface.
The Solaris 8 threads(3THR) page explicitly mentions adaptive mutexes,
the Solaris 9 threads(3THR) page has a sideways reference to them, and
in Solaris 10 I can't find a threads man page at all (I guess because
threads are in libc now). But even in Solaris 8 I can't seem to
divine the interface.
Frank
| |
| Frank Cusack 2005-06-22, 2:50 am |
| On Wed, 22 Jun 2005 00:58:56 -0700 Frank Cusack <fcusack@fcusack.com> wrote:
> Are Solaris adaptive mutexes available to userland programs? If so,
> how does one use them? Preferably there is a pthreads interface.
>
> The Solaris 8 threads(3THR) page explicitly mentions adaptive mutexes,
> the Solaris 9 threads(3THR) page has a sideways reference to them, and
> in Solaris 10 I can't find a threads man page at all (I guess because
> threads are in libc now). But even in Solaris 8 I can't seem to
> divine the interface.
Oops, I found the man page, it's threads(5) on Solaris 10. The
reference to adapative mutexes has disappeared altogether.
It also looks like I may have misread what I thought was a reference
to adaptive mutexes. S8 talks about them in reference to the 1:1
thread library, not in reference to Solaris threads.
S8: Solaris threads implement an optimized mutex and
interprocess robust mutex locks.
...
The version of the alternate threads library in Solaris 8
Update 7 has been improved ... with the addition of user-level
sleep queues and adaptive mutex locking. It is the same as
what will be the default threads library included in the
next full release of Solaris.
S9: Solaris threads implement an optimized mutex and
interprocess robust mutex locks.
S10: Solaris threads implement interprocess robust mutex locks.
It was the "optimized mutex" bit that I thought referred to the
adaptive mutex.
Frank
| |
| roger.faulkner@sun.com 2005-06-22, 5:57 pm |
|
Frank Cusack wrote:
> On Wed, 22 Jun 2005 00:58:56 -0700 Frank Cusack <fcusack@fcusack.com> wrote:
>
> Oops, I found the man page, it's threads(5) on Solaris 10. The
> reference to adapative mutexes has disappeared altogether.
>
> It also looks like I may have misread what I thought was a reference
> to adaptive mutexes. S8 talks about them in reference to the 1:1
> thread library, not in reference to Solaris threads.
>
> S8: Solaris threads implement an optimized mutex and
> interprocess robust mutex locks.
> ...
> The version of the alternate threads library in Solaris 8
> Update 7 has been improved ... with the addition of user-level
> sleep queues and adaptive mutex locking. It is the same as
> what will be the default threads library included in the
> next full release of Solaris.
>
> S9: Solaris threads implement an optimized mutex and
> interprocess robust mutex locks.
>
> S10: Solaris threads implement interprocess robust mutex locks.
>
> It was the "optimized mutex" bit that I thought referred to the
> adaptive mutex.
There is no interface for using adaptive mutexes.
All mutexes, except priority-inheritance and inter-process robust
mutexes, are treated with adaptive locking. It's automatic.
The calling thread will spin for a while at user-level, hoping to
acquire
the mutex in short order without having to block in the kernel (and
thus
avoid a system call to do the blocking). The spin ends when either:
- the spin count is reached
- the owner of the mutex is not running on a processor.
The spin count is a detail of the implementation.
Its value is commensurate with the overhead of a system call.
Also, its value doesn't matter much because of the second case.
(There is no point in spinning if the owner is not making progress.)
Some history:
The old libthread (in Solaris 8 and before) made a feeble attempt to
implement adaptive mutexes, but it didn't work very well.
The new libthread (the alternate libthread in Solaris 8) did not do
adaptive locking at all in its first implementation. It made one
attempt
at user-level, then blocked in the kernel. This was changed in Solaris
8
Update 7 when user-level sleep queues were implemented (as a
performance
enhancement, not a user-selectable option).
In Solaris 9, what had been the alternate libthread in Solaris 8 became
the only libthread, complete with user-level sleep queues and adaptive
mutex locking.
In Solaris 10, all of the threading code from libthread was folded into
libc. In effect, there is no libthread anymore. (It still exists as
a totally empty filter library, filtered onto libc. Likewise
libpthread.)
There is no performance difference between the Solaris threads
mutex_lock()
interface and the Posix threads pthread_mutex_lock() interface. They
are,
in fact, the same function with two aliases.
The man page wording about an "optimized mutex" was removed because all
mutexes, whether Posix threads or Solaris threads, are "optimized" in
the sense of adaptive locking. This is true for all of the cases:
- Solaris 8 Update 7, alternate libthread
- Solaris 9
- Solaris 10
Roger Faulkner
Sun Microsystems
| |
| Frank Cusack 2005-06-22, 5:57 pm |
| On 22 Jun 2005 09:38:58 -0700 roger.faulkner@sun.com wrote:
> Frank Cusack wrote:
....[vbcol=seagreen]
> There is no interface for using adaptive mutexes.
> All mutexes, except priority-inheritance and inter-process robust
> mutexes, are treated with adaptive locking. It's automatic.
....
Thanks for all the info!
Just to be clear, I only need to call pthread_mutex_lock() on
a PTHREAD_MUTEX_NORMAL mutex, and I will get the adaptive behavior?
I ask because pthread_mutex_lock(3) on both S9 and S10 says:
If the mutex is already locked, the calling thread blocks ...
(which is exactly the SUS definition).
Frank
| |
| roger.faulkner@sun.com 2005-06-23, 2:48 am |
|
Frank Cusack wrote:
> On 22 Jun 2005 09:38:58 -0700 roger.faulkner@sun.com wrote:
> ...
> ...
>
> Thanks for all the info!
>
> Just to be clear, I only need to call pthread_mutex_lock() on
> a PTHREAD_MUTEX_NORMAL mutex, and I will get the adaptive behavior?
> I ask because pthread_mutex_lock(3) on both S9 and S10 says:
>
> If the mutex is already locked, the calling thread blocks ...
>
> (which is exactly the SUS definition).
That's right, you will get the adaptive behavior in this case.
Remember, this is just an implementation detail, one
that is done to improve overall performance in the face
of lock contention. If some other trick to accomplish
the same goal emerges, the implementation could change.
As for the SUS[v3] definition, what does 'blocked' mean?
Makes no forward progress is the usual definition.
The caller first blocks for a while by spinning, then if
unsuccessful in acquiring the mutex while spinning, it
blocks by dropping into the kernel (which may not block at
all if the owner releases the mutex while the caller is
diving into the kernel).
The SUSv3 specification explains (a bit) what 'blocked' means
under the 'Thread Mutexes' section of the 'Threads' chapter:
A thread that has blocked shall not prevent any unblocked
thread that is eligible to use the same processing resources
from eventually making forward progress in its execution.
The key word here is 'eventually'.
Roger Faulkner
Sun Microsystems
| |
| Casper H.S. Dik 2005-06-24, 7:52 am |
| Frank Cusack <fcusack@fcusack.com> writes:
>Just to be clear, I only need to call pthread_mutex_lock() on
>a PTHREAD_MUTEX_NORMAL mutex, and I will get the adaptive behavior?
>I ask because pthread_mutex_lock(3) on both S9 and S10 says:
> If the mutex is already locked, the calling thread blocks ...
>(which is exactly the SUS definition).
Blocking is the observed behaviour; the implementation may spin
(which appears to the observer as blocking) or actually block
in the kernel.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|