Re: atomic operations...

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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: Why "lock" functionality is introduced for all the objects?
    ... very nature of objects in Java. ... synchronization, well, simple. ... can use it as a lock (strictly speaking, a Hoare monitor). ...
    (comp.lang.java.programmer)
  • 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: how to make this code thread safer?
    ... monitor during their execution, ensuring that only one thread can be ... Note the use of a dedicated object reference for synchronization. ... other code not related to your own taking the same monitor, ... Those are the simplest techniques available in Java, ...
    (comp.lang.java.programmer)
  • 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: Recommendation for HD TV 1080P
    ... You end up having to power the monitor off and back on ... One connects to a Dune HD Center via HDMI. ... I'm assuming this to an issue with the Dune player, ... synchronization of the screen. ...
    (rec.video.dvd.tech)