C# – Compact Famework lock PDA screen

Worst (won't actually work)

Change the access modifier of counter to public volatile

As other people have mentioned, this on its own isn't actually safe at all. The point of volatile is that multiple threads running on multiple CPUs can and will cache data and re-order instructions.

If it is not volatile, and CPU A increments a value, then CPU B may not actually see that incremented value until some time later, which may cause problems.

If it is volatile, this just ensures the two CPUs see the same data at the same time. It doesn't stop them at all from interleaving their reads and write operations which is the problem you are trying to avoid.

Second Best:

lock(this.locker) this.counter++;

This is safe to do (provided you remember to lock everywhere else that you access this.counter). It prevents any other threads from executing any other code which is guarded by locker. Using locks also, prevents the multi-CPU reordering problems as above, which is great.

The problem is, locking is slow, and if you re-use the locker in some other place which is not really related then you can end up blocking your other threads for no reason.

Best

Interlocked.Increment(ref this.counter);

This is safe, as it effectively does the read, increment, and write in 'one hit' which can't be interrupted. Because of this, it won't affect any other code, and you don't need to remember to lock elsewhere either. It's also very fast (as MSDN says, on modern CPUs, this is often literally a single CPU instruction).

I'm not entirely sure however if it gets around other CPUs reordering things, or if you also need to combine volatile with the increment.

InterlockedNotes:

1. INTERLOCKED METHODS ARE CONCURRENTLY SAFE ON ANY NUMBER OF COREs OR CPUs.
2. Interlocked methods apply a full fence around instructions they execute, so reordering does not happen.
3. Interlocked methods do not need or even do not support access to a volatile field, as volatile is placed a half fence around operations on given field and interlocked is using the full fence.

Footnote: What volatile is actually good for.

As volatile doesn't prevent these kinds of multithreading issues, what's it for? A good example is saying you have two threads, one which always writes to a variable (say queueLength), and one which always reads from that same variable.

If queueLength is not volatile, thread A may write five times, but thread B may see those writes as being delayed (or even potentially in the wrong order).

A solution would be to lock, but you could also use volatile in this situation. This would ensure that thread B will always see the most up-to-date thing that thread A has written. Note however that this logic only works if you have writers who never read, and readers who never write, and if the thing you're writing is an atomic value. As soon as you do a single read-modify-write, you need to go to Interlocked operations or use a Lock.

On Windows Mobile setting your form's WindowsState property to FormWindowState.Maximized will cause the form to become fullscreen covering the nav bar at the top etc.

I have done a lot of Windows Mobile <--> Windows CE porting and in general if I need to resolve differences like this I end up setting the applicable properties at runtime after I've performed a platform detection check.

Using .NET CF 3.5 you could end up with something like the following:

using Microsoft.WindowsCE.Forms;

if (SystemSettings.Platform == WinCEPlatform.WinCEGeneric)
  this.WindowState = FormWindowState.Maximized;
else
  this.WindowState = FormWindowState.Normal; // Pocket PC or Smartphone

Luckily there are not too many cases where such differences pop up.

With respect to Visual Studio prompting you to select the target platform, for the most part (atleast for.NET CF based projects) this simply changes the list of emulators and controls from the form designer toolbox that you are able to select.

In most cases you should be able to build your application against one platform and run the resultant executable on another.

One handy use of this feature is the fact that it will provide you with warnings if you attempt to use something not supported by a particular platform. For example selecting a smartphone platform will issue warnings if you attempt to use System.Windows.Forms.Button controls, since these are not supported on smartphone (non touch screen) devices.