Current Status

Thu Apr 1 00:00:00 GMT 1999

>> On 1999年2月18日, Godmar Back wrote:
>> >
> >Apropos sync_info. EF has gone public since the last discussion on this
> >topic on this list. While I don't have hard numbers, I think that their 
> >way of doing synchronization is the best I've seen so far.
> >
> >The basic idea is that they spent an additional word per object, but 
> >unlike gcj/kaffe, they spend 30 bits of it to store an object's hashcode
> >(Kaffe uses the address of an object, which doesn't work with a moving 
> >collector - what does gcj/libjava do?), and they spend 2 bits to indicate
> >that an object is locked/that the lock is contended. This optimizes
> >the common case of taking an uncontended lock.
> >
> >	- Godmar
>> Hmm.... I'd be interested in seeing an implementation of this synchronization
> strategy. I suppose that the only time it would allocate a synchronization
> object is in the case an object is already locked. Off the top of my head, I
> can't see how to easily know if I already own the monitor with just a
> single bit to indicate that an object is locked. Maybe I'm just dense right
> now...
>
While a thread owns the monitor, the hashcode is evicted and a pointer to
a slot on your own stack is written where the hashcode normally sits.
Hence, you can figure out whether you own the lock already by checking
that this pointer points to a location further up on your stack if you
encounter a locked object.
See http://www.mozilla.org/projects/ef/techdocs/design/monitors_32.html
for a nice and detailed explanation.
	- Godmar