Re: An idea of remove MUTEX_WAKE_ALL

On Tue, 3 Jan 2006, John Baldwin wrote:

> On Sunday 01 January 2006 02:21 am, prime wrote:
> > Hi hackers,
> > I have an idea about remove the kernel option MUTEX_WAKE_ALL.
> > When we unlock the mutex(in _mtx_unlock_sleep),we can directly
> > give the lock to the first thread waiting on the turnstile.And a
> > thread gets the mutex after he returned from turnstile_wait so he
> > can simply jump out the _obtain_lock loop in _mtx_lock_sleep.
> > This makes a mutex always be owned by a thread when there are threads
> > waiting on the turnstile,so priority inheritance can work now.
> > This idea need only a few changes in kern/kern_mutex.c .But when
> > NO_ADAPTIVE_MUTEXS not set,it makes threads that spinning on other CPU
> > to get the mutex have to spin for a long time,and this makes the short
> > term mutex more expensive(maybe should use spin mutex instead).
> >
> > What do think about the idea? Thanks.
>
> Sun actually found that the performance was better when you did MUTEX_WAKE_ALL
> because once you woke up N threads, if they don't all resume at once then
> they will acquire the lock in sequence and the lock acquires and releaes will
> all be simple ones rather than all being the complicated contested case.
> There are more details in _Solaris Internals_.

Yes, but doesn't this partly rely on having the threads spin(*)
for a bit if the current lock owner is running on another CPU?
Do we currently do that?

(*) No, I am not referring to spin mutexes.

--
DE

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Locking etc. (Long, boring, redundant, newbie questions)
    ... What is really meant is that depending on the type of mutex a thread is trying to acquire, the thread will either spin or it will sleep waiting for the lock to become available. ...
    (freebsd-hackers)
  • Locking etc. (Long, boring, redundant, newbie questions)
    ... sleep waiting for the lock to become available. ... mutex protects. ... if we spin for so long ...
    (freebsd-hackers)
  • Re: An idea of remove MUTEX_WAKE_ALL
    ... > This makes a mutex always be owned by a thread when there are threads ... > term mutex more expensive(maybe should use spin mutex instead). ... they will acquire the lock in sequence and the lock acquires and releaes will ...
    (freebsd-hackers)
  • adaptive mutexes, was Re: btrfs_tree_lock & trylock
    ... People seem to repeatedly come up with adaptive mutex based on intuitive ... % of time lock is contended ... overhead of entry-exit for lock primitive (spin time) ... if the contention phases are short. ...
    (Linux-Kernel)
  • Re: RT patch acceptance
    ... >>on a cpu under the assumption the lock owner's average ... >>mutex as a spin lock it cannot acquire another adaptive ... >>mutex as a blocking lock. ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)