Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Language Memory Models

research.swtch.com

Post reply on HN
Print view View original

51–60 of 101 posts

Re: Programming Language Memory Models

#51

Post by dragontamer »

mumblemumble wrote: post #46
dragontamer wrote: post #22

Earlier quoted context omitted.

Lets do this example in Java (but it should be simple enough that C#, Python, Javascript and other programmers would understand it). public void myFunction(FooObject o){ o.doSomething(); } How does the compiler know if "FooObject o" is a singleton or not? That's the thing about the "Singleton" pattern, you have an effective "global-ish" variable, but all of your code is written with normal pass-the-object style. EDIT…

Is there anything special about singletons here? In Java, there's no real difference between a singleton and any other object. A singleton is an object that just happens to have a single instance. Practically speaking, they're typically used as a clever design pattern to "work around" Java's lack of language-level support for global variables, so there's that. But I think that that fact might not be relevant to the i…

> Is there anything special about singletons here?

No, aside from the fact that the root commenter clearly understands the issue with global variables, but not necessarily singletons.

I'm trying to use the singleton concept as a "teaching bridge" moment, as the Singleton is clearly "like a global variable" in terms of the data-race, but generalizes to any object in your code.

The commenter I'm replying seems to think that global-variables are the only kind of variable where this problem occurs. He's wrong. All objects and all variables have this problem.

Re: Programming Language Memory Models

#52

Post by dragontamer »

Kranar wrote: post #49
mumblemumble wrote: post #45

Earlier quoted context omitted.

In a lot of code I've seen, there are threads polling some variable without using any sort of special guard. The assumption (based, I assume, on how you really could get away with this back in the days of single-core, single-CPU computers) is that you only need to worry about race conditions when writing to primitive variables, and that simply reading them is always safe.

Okay but the poster mentioned a mutex, which would not be a good way to go about polling a variable in Java. All you need to guarantee synchronization of primitive values in Java is the use of volatile [1]. If you need to compose atomic operations together, then you can use an atomic or a mutex, but it would not occur to me to use a mutex to perform a single atomic read or write on a variable in Java. [1] https://doc…

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-cst default access very similar to Java's volatile semantics).

-----------

Anyway, put yourself into the mindset of a 2009-era C++ programmer for a sec. InterlockedIncrement works on Windows but not in Linux. You got atomics on GCC, but they don't work the same as Visual Studio atomics.

Answer: Mutex lock and mutex-unlock. And then condition variables for polling. Yeah, its slower than InterlockedIncrement / seq-cst atomic variables with proper memory barriers, but it works and is reasonably portable. (Well, CriticalSections on Windows because I never found a good pthreads library for Windows)

------

Its still relevant because you still see these thread issues come up in old C++ code.

Re: Programming Language Memory Models

#53

Post by romesmoke »

I'm wondering: is the fact that a CS PhD finds resources like this as much amusing as educational/pedagogical gold telling something for the Academia, the Culture, or the Self?

AKA why can't I stumble upon such stuff more often. Thanks OP!

Re: Programming Language Memory Models

#54

Post by eternalban »

pjmlp wrote: post #42
voidnullnil wrote: post #16

Earlier quoted context omitted.

How many programmers do you know put locks around polling varibles for seemingly no reason (as they are not cognizant of the memory model)?

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

Re: Programming Language Memory Models

#55

Post by ithkuil »

bullen wrote: post #37
pphysch wrote: post #31

Earlier quoted context omitted.

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

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 (already?) security will mean real money and life or death situation for companies; keeping that much code in a language where nobody can promise a memory corruption will not be introduced in the next commit, is eventually not going to be considered acceptable anymore.

yes, Go is sponsored by a mega corp, yes, and some people cringe at that, but realistically it's less a walled garden than c#, swift or stuff like that.

Rust is likely going to fill the niche currently occupied by C++ but it's quite hard to learn and use.

So yes, it's quite possible that we'll all flock to something new and shiny in 10 years time and forget Go before 20 years have passed. But, whatever replaces Go needs to fill its niche, which if you think about it doesn't have that much free design space left; yes you can improve a few things here and there, but then you have to fight with the massive code base and libraries, that stays relevant due to the absolutely fantastic backward compatibility promises. I've seen C code rot due to compilers getting "better" over time (yes, sure, the C code in question was obviously "wrong", but nobody noticed, because writing correct C code is an exercise in divination)

Re: Programming Language Memory Models

#56

Post by Kranar »

dragontamer wrote: post #52
Kranar wrote: post #49

Earlier quoted context omitted.

Okay but the poster mentioned a mutex, which would not be a good way to go about polling a variable in Java. All you need to guarantee synchronization of primitive values in Java is the use of volatile [1]. If you need to compose atomic operations together, then you can use an atomic or a mutex, but it would not occur to me to use a mutex to perform a single atomic read or write on a variable in Java. [1] https://doc…

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 a standard library providing atomic data types and atomic instructions. Prior to the standardization one used platform specific atomic facilities. boost has provided cross-platform atomic operations that work on virtually every platform since 2002. Prior to 2002 there were no multicore x86 processors. There would have been mainframe computers that were multicore, is it your argument that code written for those mainframes are of relevant use today by fairly typical C and C++ developers?

At any rate, at no point did any of Java, C, or C++ require the use of a mutex in order to properly synchronize access to a "polling variable". Atomic operations were widely available to all three languages in various ways and would have been the preferred method.

Re: Programming Language Memory Models

#57

Post by butterisgood »

bullen wrote: post #37
pphysch wrote: post #31

Earlier quoted context omitted.

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

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.

That’s like, just your opinion man.

Re: Programming Language Memory Models

#58

Post by mbrodersen »

pjmlp wrote: post #43
skohan wrote: post #27

Earlier quoted context omitted.

I'm sorry is this comment from 1998? I've been working in software for over a decade, and I haven't seen server work being done in Java in ages. From my perspective, Go in the context of serverless programming seems to currently be the best choice for server-side programming. In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn &…

And I haven't seen server work done in C++ since 2006, we keep replacing those systems with Java and .NET ones. To each its own.

I have seen new server work being done in C++ every year the last 10 years. So yes we all have different experiences.

Re: Programming Language Memory Models

#59

Post by mbrodersen »

bullen wrote: post #37
pphysch wrote: post #31

Earlier quoted context omitted.

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

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.

The world banking system is running on COBOL. Perhaps not “interesting” for you but without it pretty much everything would stop working.

Re: Programming Language Memory Models

#60

Post by voidnullnil »

Kranar wrote: post #49
mumblemumble wrote: post #45

Earlier quoted context omitted.

In a lot of code I've seen, there are threads polling some variable without using any sort of special guard. The assumption (based, I assume, on how you really could get away with this back in the days of single-core, single-CPU computers) is that you only need to worry about race conditions when writing to primitive variables, and that simply reading them is always safe.

Okay but the poster mentioned a mutex, which would not be a good way to go about polling a variable in Java. All you need to guarantee synchronization of primitive values in Java is the use of volatile [1]. If you need to compose atomic operations together, then you can use an atomic or a mutex, but it would not occur to me to use a mutex to perform a single atomic read or write on a variable in Java. [1] https://doc…

The idea is that 99% of Java devs have no idea what volatile does, if they even have heard of it. Their vocabulary is mutex, semaphore, deadlock, and they might think atomic word64 is simply like a low level efficient lock around two 32 bit words.

Ergo, when they come across the consideration of whether a static bool needs to be locked before reading and writing from separate threads, they fall into one of two invalid schools of thought:

1. "It doesn't need a lock, because it can only be true or false, it is essentially atomic."

2. "It needs a lock, because it is accessed by multiple threads and my teacher said concurrent data needs to be synchronized with a lock."

This isn't just about Java devs though, it applies to all languages with "the memory model". Literally the only reason you'd know better is if you read specs, or are into playing with raw hardware / assembly / C (I'd say the situation is better in C, about 50% instead of 99%. I meet C programmers all the time who think they can poll a variable without any additional code).

Post reply on HN