C# 4.0 (dynamic types, optional parameters, named arguments, covariants and contravariants handling)

New features of C# 4.o are presented in several places.
Ironically the most exposed is Doug Holland's at Intel's blog site :) - nice and very brief overview.
More info at Channel9 video provided by C# GoF :). The most striking facts are:

1. dynamic typing is for better Office interaction,
2. optional parameters and named arguments are evil, provided for VB developers to ease Office development in C#,
3. covariance and contravariance are only interesting (good) changes in language, but it should have appeared in previous versions of C#.

Additionally more about covariance and contravariance is on Eric Lippert's blog and more about dynamic programming on Chris Burrows' blog.

volatile - what does it mean? (in C++, C, .NET and Java)

Well it is good felling that my interests are also Herb Sutter interests (in programming area of course:). In his article on Dr. Dobb's he presents differences between volatile meanings in different words (C++/C vs. .NET/Java).

Main points:

• volatile in C++ is connected to optimization during access to variable - no optimization is allowed. Operations on nearby non volatile variables depends on compiler (can be move before or after volatile operation).
• operations on volatile in C++ does not guarantee atomicity - resolution is atomic in C++ (or e.g. atomic_int in C) available in Boost (but I cannot find it) and will be in C++0x.
• volatile in managed environments (.Net, Java) does not allow to move some operations on nearby non volatile variables - "ordinary reads and writes can't move upward across (from after to before) an ordered atomic read, and can't move downward across (from before to after) an ordered atomic write. In brief, that could move them out of a critical section of code, and you can write programs that can tell the difference.".

volatile in .Net/Java:

• keeps order - lock free programming,
• allows some code optimizations - not good for interactions with hardware - but BTW managed environments does not allow to treat memory as a resource to write somewhere programmer might like to - unmanaged code have to be used (e.g. C++ with its volatile:).

volatile in C++/C:

• might not keep order - depends on compiler,
• does not allow code optimization - good for interactions with hardware.
  

Generally speaking volatile in C++ means unoptimizable variable (optimizations in access are not allowed) and in managed worlds it means ordered atomics (other operations cannot move before/after and operations on volatile are atomic - sometimes?).

Not sure points:

• atomicity of volatile operations in .Net/Java - for what variables, e.g. what about architectures 32, 64?,
• "These (volatile) are suitable for nearly all lock-free code uses, except for rare examples similar to Dekker's algorithm. .NET is fixing these remaining corner cases in Visual Studio 2010" - what are the problems?

Optex, fairness v.s. convoys and critical regions

Interesting, but quit old article concerning synchronization (with fairness, convoys considerations) by Jeffrey Richter can be found at http://msdn.microsoft.com/en-us/magazine/cc163642.aspx.

According to author fairness cannot be assured in .NET - main reason is GC. GC has to suspend threads before execution but sometimes suspended is a thread that invokes unmanaged Win32 WaitForSingleObject or WaitForMultipleObjects function. After wake up order in waiting queue can be different than original. Other sources of lacking fairness are APC and debugger.

Optex synchronization mechanism:

• point of the presented solutions is to avoid switching into kernel mode (interlocked is used for this task),

• latter of the presented solutions allows new coming threads pass before threads waiting in semaphore queue (waiting in kernel mode). This unfair solution, in case of constant stream of threads requesting enter, has better throughput than former kernel unlocking solution,

• fairness is completely sacrificed to avoid convoy problem.

Also some words concerning Critical Regions appear in the article:

• "hand made" synchronization mechanisms shall invoke BeginCriticalRegion in Enter and EndCriticalRegion in Exit,

• the mechanism informs CLR host that thread was interrupted (aborted) in critical region and some special action shall be performed (e.g. closing appdomain)

Question - how host is informed?

More Jeffrey Richter on MSDN Magazine - http://msdn.microsoft.com/en-us/magazine/cc301191.aspx