Re: fast mutexes for 1.8?

On Sun, 2006-11-12 at 17:38 +0900, Brent Roman wrote:
> I'll take your word that the pthread and Java specs remain silent on
> this issue.

pthreads doesn't appear to require anything more specific than "wake
some and let the scheduler sort it out", whereas the Java language
specification requires "non-fair" wake-one behavior.

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8.2

> Implementing a "fair" mutex atop a native mutex would require
> that the native library and Ruby both manage queues of waiting threads.
> So, I cannot see how it will be faster than a "fair" mutex atop O(1)
> test-and-set operations, although, the overhead for the
> native library's thread queue management will admittedly be quite
> small compared to Ruby's.
> 
> Am I missing an important point here?

No, actually I think you're correct at this point.  I won't be adding an
Atomic primitive as part of this particular library, since its goal is
to simply optimize the existing primitives without any significant
changes in behavior, but I think it is something that's worth doing
separately.

FWIW, I don't think there's a strong reason to limit it to Fixnums; you
probably had atomic_t in mind, but that won't be an issue for e.g. JRuby
and probably other implementations.  May as well let Atomic store a
reference to any Object.

-mental