On Nov 6, 2006, at 10:02 AM, Joshua Haberman wrote:
> On Mon, 2006-11-06 at 09:38, MenTaLguY wrote:
>> On Mon, 2006-11-06 at 23:21 +0900, khaines / enigo.com wrote:
>>> So, what would you suggest as a performance optimization to Mutex?
>>
>> Principally, pushing the whole thing into C and using a better data
>> structure than a dynamically allocated C array of VALUEs (what  
>> underlies
>> Array) for the wait queue.
>
> If we are using native threads, why not use whatever native mutexes  
> the
> operating system provides?
>
> Sure, it opens you up to OS-specific bugs/gotchas, but that is also  
> true
> of using native threads at all.  It also opens you up to OS-specific
> optimizations (like futexes).
>
> I am slightly alarmed that this question is still open at this point.
> If YARV is moving Ruby from green threads to native threads, I would
> expect the important questions about what this will mean for
> synchronization (for both C-level extensions and Ruby) to have been
> resolved by now.  Is there a global interpreter lock like Python?   
> What
> is the migration path for people using Thread.critical?  In what cases
> will C extensions have to change?
>
> Are answers to these questions known?

Yes.  Have you read Koichi's presentations?

-- 
Eric Hodel - drbrain / segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com