61–70 of 101 posts
These "memory models" are too complex for languages intended for dilettante developers. It was a disaster in Java/C#. Not even more than a handful of programmers in existence know in depth how it works, as in, can they understand any given trivial program in their language. At best they only know some vague stuff like that locking prevents any non visibility issues. It goes far deeper than that though (which is also…
Earlier quoted context omitted.
Well, while it may appear gatekeeping, maybe those dilettante developers should be using something else instead, like BASIC?
Aha. The other day you were arguing for education as a silver bullet /g
So here is my argument, maybe those developers should bother to actually learn about what they are trying to do in first place.
These "memory models" are too complex for languages intended for dilettante developers. It was a disaster in Java/C#. Not even more than a handful of programmers in existence know in depth how it works, as in, can they understand any given trivial program in their language. At best they only know some vague stuff like that locking prevents any non visibility issues. It goes far deeper than that though (which is also…
Source?
Earlier quoted context omitted.
That's Java's Object.lock() mechanism. All variables inside of an object (aka: any class) are assumed to be related to each other. synchronized(foobar_object){ baz(); } ensures that all uses of foobar_object inside the synchronization{} area are sequential (and therefore correct). -------- The issue is that some people (a minority) are interested in "beating locks" and making something even more efficient.
In Java, any object can be used to synchronize any data, e.g. synchronized(foobar_object){ foo(); } synchronized(foobar_object){ bar(); } synchronized(foobar_object){ baz(); } Will have foo, bar, baz methods well behaved in any data that they share regardless of whether they are foobar methods or methods of any other class(es). It is exactly analogous to the S(a) -> S(a) synchronizing instruction from the article tha…
I highly advise reading "Java Concurrency in Practice".
Note that future Java primitive classes don't have monitors.
Earlier quoted context omitted.
COBOL is not around in anything interesting, and trust me go is not going to be used to build anything that we'll use in 20 years.
I agree that C is not going to die soon. But don't dismiss Go so easily; it hits an interesting sweet spot that may not go away any time soon. It's a simple language with a simple spec, so simple that people are complaining it's too simple a language, yet also simple to use thanks to the GC. But also compiled and fast enough. But most important of all, it's memory safe and not plagued by undefined behaviour. Soon (al…
It is now where C++ was in the early-1990's.
A GPU followup to this article. While on CPU sequentially consistent semantics are efficient to implement, that seems to be much less true on GPU. Thus, Vulkan completely eliminates sequential consistency and provides only acquire/release semantics[1]. It is extremely difficult to reason about programs using these advanced memory semantics. For example, there is a discussion about whether a spinlock implemented in te…
Is this true? AcqRel seems to be accepted by the compiler for the success ordering of compare_exchange_weak.
Earlier quoted context omitted.
Java is somewhat cheating, because it got its memory model figured out years before other languages like C or C++. In C++, you'd have to use OS-specific + compiler-specific routines like InterlockedIncrement64 to get guarantees about when or how it was safe to read/write variables. Not anymore of course: C++11 provides us with atomic-load and atomic-store routines with the proper acquire / release barriers (and seq-c…
I don't understand the relevance of your point. The point I originally asked for clarification about was the use of a mutex for a "polling variable". Java has had volatile variables since the year 2000, I don't see how it's cheating that Java provided a standardized way of accessing a synchronized value before C and C++ did. Can you elaborate on your point that it's cheating? In C and C++, for 10 years now, there is…
Earlier quoted context omitted.
> Access to any global variable should always occur direct from memory. What if your function takes a pointer that might be pointing to a global variable? Does that mean that all accesses through a pointer are now excempt from optimization unless the compiler can prove that the pointer will never point to a global variable?
What if your function takes a pointer that might be pointing to an "atomic" variable? Pointers can be used to circumvent most safety measures. If you obscure the access, you should assume responsibility for the result.
These "memory models" are too complex for languages intended for dilettante developers. It was a disaster in Java/C#. Not even more than a handful of programmers in existence know in depth how it works, as in, can they understand any given trivial program in their language. At best they only know some vague stuff like that locking prevents any non visibility issues. It goes far deeper than that though (which is also…
A GPU followup to this article. While on CPU sequentially consistent semantics are efficient to implement, that seems to be much less true on GPU. Thus, Vulkan completely eliminates sequential consistency and provides only acquire/release semantics[1]. It is extremely difficult to reason about programs using these advanced memory semantics. For example, there is a discussion about whether a spinlock implemented in te…
> I'll also note that using AcqRel semantics is not provided by the Rust version of compare_exchange_weak (perhaps a nit on TFA's assertion that Rust adopts the C++ memory model wholesale), so if acquire to lock the spinlock is not adequate, it's likely it would need to go to SeqCst. Is this true? AcqRel seems to be accepted by the compiler for the success ordering of compare_exchange_weak.
It's accepted by the compiler, but if provided, it compiles to a panic.