Here is an example of what looks to be a bug in the Compact Framework when
executing under Windows CE.

If you run it on XP, you get the right result. "Done. state=Finished".
If you run it on the emulator, you get the wrong result. "Done.
state=Inside the lock".
This is very strange, and could be very bad because part of finally code
won't be executed.



using System;
using System.Threading;

namespace ConsoleApplication9
{
class Program
{
static public string state = string.Empty;
private static readonly object theLock = new object();
static void Main(string[] args)
{
try
{
try
{
state = "Starting";
throw new Exception("Exception!!!");
}
finally
{
lock (theLock)
{
state = "Inside the lock";
}
state = "Finished";
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
Console.WriteLine("Done. state=" + state);

Thread.Sleep(Timeout.Infinite);
}
}
}

This does look like a bug as I have just tried it using CF2 on PPC 2003 SE. I
suggest you raise it with the CF team.
However, not sure why you'd ever try to lock a readonly object.

Simon.
"Skin Diver" wrote:

> Here is an example of what looks to be a bug in the Compact Framework when
> executing under Windows CE.
>
> If you run it on XP, you get the right result. "Done. state=Finished".
> If you run it on the emulator, you get the wrong result. "Done.
> state=Inside the lock".
> This is very strange, and could be very bad because part of finally code
> won't be executed.
>
>
>
> using System;
> using System.Threading;
>
> namespace ConsoleApplication9
> {
> class Program
> {
> static public string state = string.Empty;
> private static readonly object theLock = new object();
> static void Main(string[] args)
> {
> try
> {
> try
> {
> state = "Starting";
> throw new Exception("Exception!!!");
> }
> finally
> {
> lock (theLock)
> {
> state = "Inside the lock";
> }
> state = "Finished";
> }
> }
> catch (Exception e)
> {
> Console.WriteLine(e.ToString());
> }
> Console.WriteLine("Done. state=" + state);
>
> Thread.Sleep(Timeout.Infinite);
> }
> }
> }
>
>
>
>
>
>

Hello Simon,

I don't have anything meaningful to add to the discussion (seeing as this
is apparently a bug in the CF CLR), but I did want to mention that objects
that do not change across the lifetime of a class instance (such as lock
objects of the kind used below) - particularly static ones - make perfect
sense to mark with readonly; it can save you a whole heap of accidental trouble
later if you've erroneously reinitialized the field somewhere.

Regards,
Tomer Gabel (http://www.tomergabel.com)
Monfort Software Engineering Ltd. (http://www.monfort.co.il)


> This does look like a bug as I have just tried it using CF2 on PPC
> 2003 SE. I
> suggest you raise it with the CF team.
> However, not sure why you'd ever try to lock a readonly object.
> Simon.
> "Skin Diver" wrote:
>> Here is an example of what looks to be a bug in the Compact Framework
>> when executing under Windows CE.
>>
>> If you run it on XP, you get the right result. "Done.
>> state=Finished".
>> If you run it on the emulator, you get the wrong result. "Done.
>> state=Inside the lock".
>> This is very strange, and could be very bad because part of finally
>> code
>> won't be executed.
>> using System;
>> using System.Threading;
>> namespace ConsoleApplication9
>> {
>> class Program
>> {
>> static public string state = string.Empty;
>> private static readonly object theLock = new object();
>> static void Main(string[] args)
>> {
>> try
>> {
>> try
>> {
>> state = "Starting";
>> throw new Exception("Exception!!!");
>> }
>> finally
>> {
>> lock (theLock)
>> {
>> state = "Inside the lock";
>> }
>> state = "Finished";
>> }
>> }
>> catch (Exception e)
>> {
>> Console.WriteLine(e.ToString());
>> }
>> Console.WriteLine("Done. state=" + state);
>> Thread.Sleep(Timeout.Infinite);
>> }
>> }
>> }

I'm not saying the object should be not marked readonly, rather there is
little point is locking a readonly object. In fact this just increases a
unnessessary performance overhead. The only other reason you might use lock
in this kind case which acts as a dummy variable is if you only ever want one
thread to access a routine at once which could be database access, global
variables or just a procedure that should never be run by more than one
thread etc.

Anyway the example code is contained within the Main method so would never
have more than one thread.

Simon.


"Tomer Gabel" wrote:

> Hello Simon,
>
> I don't have anything meaningful to add to the discussion (seeing as this
> is apparently a bug in the CF CLR), but I did want to mention that objects
> that do not change across the lifetime of a class instance (such as lock
> objects of the kind used below) - particularly static ones - make perfect
> sense to mark with readonly; it can save you a whole heap of accidental trouble
> later if you've erroneously reinitialized the field somewhere.
>
> Regards,
> Tomer Gabel (http://www.tomergabel.com)
> Monfort Software Engineering Ltd. (http://www.monfort.co.il)
>
>
> > This does look like a bug as I have just tried it using CF2 on PPC
> > 2003 SE. I
> > suggest you raise it with the CF team.
> > However, not sure why you'd ever try to lock a readonly object.
> > Simon.
> > "Skin Diver" wrote:
> >> Here is an example of what looks to be a bug in the Compact Framework
> >> when executing under Windows CE.
> >>
> >> If you run it on XP, you get the right result. "Done.
> >> state=Finished".
> >> If you run it on the emulator, you get the wrong result. "Done.
> >> state=Inside the lock".
> >> This is very strange, and could be very bad because part of finally
> >> code
> >> won't be executed.
> >> using System;
> >> using System.Threading;
> >> namespace ConsoleApplication9
> >> {
> >> class Program
> >> {
> >> static public string state = string.Empty;
> >> private static readonly object theLock = new object();
> >> static void Main(string[] args)
> >> {
> >> try
> >> {
> >> try
> >> {
> >> state = "Starting";
> >> throw new Exception("Exception!!!");
> >> }
> >> finally
> >> {
> >> lock (theLock)
> >> {
> >> state = "Inside the lock";
> >> }
> >> state = "Finished";
> >> }
> >> }
> >> catch (Exception e)
> >> {
> >> Console.WriteLine(e.ToString());
> >> }
> >> Console.WriteLine("Done. state=" + state);
> >> Thread.Sleep(Timeout.Infinite);
> >> }
> >> }
> >> }
>
>
>