Related articles |
---|
compiling locks/ monitors arnabde03@gmail.com (Arnab De) (2009-11-11) |
Re: compiling locks/ monitors felipeangriman@gmail.com (Felipe Angriman) (2009-11-13) |
Re: compiling locks/ monitors rogers.email@gmail.com (Ian Rogers) (2009-11-13) |
Re: compiling locks/ monitors andrew@tomazos.com (Andrew Tomazos) (2009-11-21) |
From: | Felipe Angriman <felipeangriman@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 13 Nov 2009 13:01:31 -0300 |
Organization: | Compilers Central |
References: | 09-11-037 |
Keywords: | parallel |
Posted-Date: | 15 Nov 2009 17:44:49 EST |
Hi,
> Can anyone tell me how these locks/monitors are
> typically and efficiently compiled?
If you look at the .NET languages you will find that this "languages
features" are typically implemented as calls to methods.
The 'lock' feature on c# is implemented via calls to the Monitor class.
For instance, the following c# fragment
private static void Main(string[] args)
{
object obj = new object();
lock (obj)
{
}
}
is compiled to the following IL
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 2
.locals init (
[0] object obj,
[1] object CS$2$0000)
L_0000: nop
L_0001: newobj instance void [mscorlib]System.Object::.ctor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: dup
L_0009: stloc.1
L_000a: call void [mscorlib]System.Threading.Monitor::Enter(object)
L_000f: nop
L_0010: nop
L_0011: nop
L_0012: leave.s L_001c
L_0014: ldloc.1
L_0015: call void [mscorlib]System.Threading.Monitor::Exit(object)
L_001a: nop
L_001b: endfinally
L_001c: nop
L_001d: ret
.try L_0010 to L_0014 finally handler L_0014 to L_001c
}
Normally this "features" are implemented by classes which wrap O.S.
objects that do the hard work.
> Can you cite any paper on this?
No, don't know papers to recommend on this matter.
HTH,
Felipe
Return to the
comp.compilers page.
Search the
comp.compilers archives again.