Re: atomic operations...

On Mon, 03 Aug 2009 17:42:24 -0700, Chris M. Thomasson <no@xxxxxxxxxxxx> wrote:

[...]
No MUTEXS!

Is that a hard design requirement? It seems arbitrary to me. Besides, the Monitor class in .NET isn't strictly speaking a Windows mutex (as in the unmanaged CreateMutex() function).

Until you've measured and confirmed a genuine performance problem, IMHO you should not care so much about the specific synchronization mechanism used.

That said...

Java can accomplish this in a 100% non-blocking manner on platform which support it.

Not exactly. The Java implementation trades synchronization in the class itself for synchronization in the memory manager. The implementation I showed doesn't have to perform any allocations, nor does it cause work for the GC as part of its operation.

Also, careful with that word "blocking". Even an interlocked CPU instruction can block; it has to, just as atomic writes to memory locations have to block at some level. It's just that CPU-level synchronization is generally less expensive than OS-level synchronization mechanisms.

Of course, if for some reason you prefer the performance penalty of object allocation and collection over the performance penalty of a monitor, you could simply adjust my implementation to match the Java implementation (which you can find here: http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Core/Collections-Jar-Zip-Logging-regex/java/util/concurrent/atomic/AtomicStampedReference.java.htm).

This would in fact be similar to what it _looks_ like you were trying to do originally, but unsuccessfully. Then you can use the Interlocked methods to perform the exchange on the value/stamp pair object references, rather than locking around the store values in a single class. This is done as easily in C# as in Java.

It seems like your saying that I have to use locks and monitors in C# in order to get similar functionality.

No, you don't have to. It's just that given your original question, it wasn't clear at all that was something you are concerned about.

Note: there's no "locks and monitors" in C#. The "lock()" statement is simply a shorthand way of using the Monitor class. It's the same thing.

Note also: using the Interlocked class is not a performance panacea. It still involves hardware level synchronization, and that's every bit as much a performance risk as monitors, depending on usage. If a CPU core stalls somewhere because some other core was doing an atomic compare-and-exchange, that can cause delays or other problems that have noticable effects on performance, sometimes dramatically so.

That's fine. I was just wondering if I can get C# to create code that does not use expensive mutexs,

Again, "expensive" compared to what? Until you've identified synchronization as a specific bottleneck in your code, trying to avoid a specific synchronization mechanism is a waste of your valuable time.

I don't think its possible in 100% pure C# managed code.

In pure C# you can implement a class that has exactly the same performance characteristics as the Java class you're talking about.

I can create a library in which C# can get non-blocking DWCAS. But, that's not ideal.

You can use "unsafe" and get a 32-bit pointer to an object instead of a reference, and then proceed to pack that into an Int64 with your Int32 "stamp". Then you can use the Interlocked.CompareExchange(Int64, Int64, Int64) overload.

Other than that, AFAIK a library (e.g. managed C++/CLI or plain C called via p/invoke) is the only way you'd be able to use the CMPXCHG8 instruction from C#, and using that is the only way to atomically modify 8 bytes at once. Java has basically the same limitations; you'd have to use an unsafe mechanism (e.g. JNI) to convert a Java reference to a pointer that can be packed into a 64-bit word, which can then be compared and exchanged atomically.

Please note that you seem to be asking two different, contradictory questions here: you initially wanted an implementation of an existing Java class. Then you said you wanted an implementation that's equivalent to the ASM code you posted. Those two are not the same, so it's hard to understand exactly what you do want.

[...]
BTW, can you think of a way that C# can do this? I would be GRATEFUL if you can perhaps HACK something together without resorting to unsafe unmanaged code!

Sure. Just port the Java implementation to C#. I wouldn't bother, but you can do it if you want. Just remember to use "out" arguments instead of the silly "pass a single-item array" workaround needed in Java.

Pete
.

Relevant Pages

  • Re: About synchronization methods
    ... The Java guys themselves admit that what Java has is ... not the true monitor but some low level means to implement a monitor- ... Once you name the language, please name the one true language that is worthy enough to implement the runtimes/virtual-machine for its holiness. ... In fact, as I've pointed out before in detail, the whole "language supported" synchronization model of Java is nothing more than very shallow semantic sugar over the standard library mutex and condition variable synchronization model. ...
    (comp.programming.threads)
  • Re: Event Viewer
    ... Restore attempts to monitor a hidden partition. ... Include your translation of the error message, the information about Java, ... Tipo de evento: Erro ...
    (microsoft.public.windowsxp.general)
  • Re: Block in synchronized mathod
    ... Where are those coming from in a Java ... malice, or possibly by design. ... but using coarse-grained monitors when you're waiting ... (remember you can use any old Object as a monitor). ...
    (comp.lang.java.help)
  • Java + Monitor Issues
    ... Whether I am on or off line, if I use Java web start or open a Java run applet, my monitor goes black. ... I am using Windows XP Home Ed's drivers for my monitor as they are newer than the drivers provided by Hitachi dating from 1999. ...
    (microsoft.public.windowsxp.general)
  • Re: posix and lock-free algorithms
    ... I know an early Java compiler optimized out empty ... > formal semantics it's likely to be similar to Java. ... compromise between usefulness and implementability in these areas. ... I mean memory synchronization, which operations should be ...
    (comp.programming.threads)