Re: compiling locks/ monitors

On Nov 11, 6:08 am, Arnab De <arnabd...@gmail.com> wrote:
> Many modern high level languages like Java/ C# have locks/ monitors as
> language level features. Hardwares typically have lower level
> synchronization primitives like CAS. One can implement a spinlock
> using CAS, but it is bad for performance as it busy-waits for the lock
> to be released. Can anyone tell me how these locks/monitors are
> typically and efficiently compiled? Can you cite any paper on this?


Hi Arnab,


for Java the papers you should look at are on thin locking [1] and
then on lock reservation/biasing [2][3]. A thin lock is a word in an
object that you assume will show that an object is not locked and then
you try to swap in your thread ID, if your compare and swap found a
non-zero value you have contention and then you need a fat lock (a
separate data structure). On releasing the thin lock you do a compare
and swap and if your thread ID has been changed to a fat lock
reference then you need to go to the fat lock to wake up a contending
thread. Lock reservation changes this so that on the release you do no
work (no CAS), instead contending threads add themselves to a list of
contending threads paired with objects that when crossing a safepoint
are processed. With reservation an object is often owned by your
thread (biased to it or reserved by it) and to check the thread still
owns the lock you don't need a full CAS, just a load (hence locking
with no atomic operations). In Java locks can be held recursively,
adding complexity. You also may not want lock reservation/biasing in
some performance scenarios, and you may want to busy wait in some
scenarios too.


Regards,
Ian Rogers


[1] http://www.research.ibm.com/people/d/dfb/thinlocks.html
[2] http://doi.acm.org/10.1145/582419.582433 - Lock reservation: Java
locks can mostly do without atomic operations
[3]
http://java.sun.com/javase/technologies/hotspot/publications/biasedlocking_oo
psla2006_wp.pdf

Return to the comp.compilers page.
Search the comp.compilers archives again.