4 ms·

In my case it was about trying to make Java threads work in a situation where pre-emptive scheduling was needed for very many threads. The problem with the JVMs

by mzl 16y ago

In my case it was about trying to make Java threads work in a situation where pre-emptive scheduling was needed for very many threads. The problem with the JVMs I tried was that they all started too many OS threads, and I couldn't get them to limit this enough. I might have done something wrong though. My general feel is that the threading model is too underspecified in Java. I haven't been doing Java for a while now, but I hope that the situation has become better. The Erlang model of starting threads for all the tasks to do is very alluring once one gets used to it :)

lemming 16y ago
It may be very alluring but it's not going to work on Java since the model is different, and if you try to emulate Erlang on Java you're in for at least one surprise. This doesn't mean it's underspecified, in fact Java has arguably the most completely specified concurrency and memory model around. You just have to understand how it works to get the most out of it, like anything.
- mzl 16y ago
  The memory model is nicely specified, given that the program is race-free. If it isn't, then all bets are off. There are a lot of programs that are not race-free (although he races in themselves might be benign), and as such have a very weak memory model. The concurrency model does have a very weak specification. It essentially says that a) threads exist, and b) threads with the highest priority will run at some point in time. This specification was left purposefully vague, AFAIK, so that a JVM implementation can rely on OS threads. Unfortunately, it also means that the programmer has to be aware of the specifics of all relevant JVM+OS combinations where a particular program is run. This is what I meant with underspecified, although I understand the reason for it.
  - lemming 16y ago
    This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is not a property of the program, it's a property of the platform - since in Java you're programming to the JVM platform, the fact that the platform is very exactly specified is what allows you to show that your program is race free. I think you're looking for a very different sort of specification than what the JMM provides. It doesn't provide you with exact specifications of exactly how threads will behave, but no system that I'm aware of completely specifies that and any program that relies on that is fundamentally broken on any platform except exactly one version of one platform anyway - that which it was written and tested on. It's simply too dependent on the exact OS and version, the exact version of the processor, and a million other factors you can't control. Instead, the JVM, the JMM and company work together to exactly specify the interactions between threads that are safe. It turns out that this really is all you need to know to write correct concurrent programs, and you don't have to worry about combinations of anything, or how threads are implemented, or how many processors are available, etc etc. Additionally, with the j.u.c libraries in Java 5+ there are sufficiently good abstractions that you don't need to worry about any of this low level gore much. Seriously, if you're going to be writing multithreaded code in Java, read the book. It's awesome.
  - motxilo 16y ago
    No, the JMM specification is not vague. Abridged, it provides a minimum set of guarantees in terms of data visibility between threads -happens-before rules- that the application programmer can expect. Think of it as an abstraction layer that portrays an uniform view of the myriad of hardware configurations on which the JVM runs -e.g. cache coherence strategies-, thus relieving the programmer from the burden of knowing the nuts and bolts of the target system for which its code is intended.

by mzl 16y ago

lemming 16y ago

It may be very alluring but it's not going to work on Java since the model is different, and if you try to emulate Erlang on Java you're in for at least one surprise. This doesn't mean it's underspecified, in fact Java has arguably the most completely specified concurrency and memory model around. You just have to understand how it works to get the most out of it, like anything.

mzl 16y ago
The memory model is nicely specified, given that the program is race-free. If it isn't, then all bets are off. There are a lot of programs that are not race-free (although he races in themselves might be benign), and as such have a very weak memory model. The concurrency model does have a very weak specification. It essentially says that a) threads exist, and b) threads with the highest priority will run at some point in time. This specification was left purposefully vague, AFAIK, so that a JVM implementation can rely on OS threads. Unfortunately, it also means that the programmer has to be aware of the specifics of all relevant JVM+OS combinations where a particular program is run. This is what I meant with underspecified, although I understand the reason for it.
- lemming 16y ago
  This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is not a property of the program, it's a property of the platform - since in Java you're programming to the JVM platform, the fact that the platform is very exactly specified is what allows you to show that your program is race free. I think you're looking for a very different sort of specification than what the JMM provides. It doesn't provide you with exact specifications of exactly how threads will behave, but no system that I'm aware of completely specifies that and any program that relies on that is fundamentally broken on any platform except exactly one version of one platform anyway - that which it was written and tested on. It's simply too dependent on the exact OS and version, the exact version of the processor, and a million other factors you can't control. Instead, the JVM, the JMM and company work together to exactly specify the interactions between threads that are safe. It turns out that this really is all you need to know to write correct concurrent programs, and you don't have to worry about combinations of anything, or how threads are implemented, or how many processors are available, etc etc. Additionally, with the j.u.c libraries in Java 5+ there are sufficiently good abstractions that you don't need to worry about any of this low level gore much. Seriously, if you're going to be writing multithreaded code in Java, read the book. It's awesome.
- motxilo 16y ago
  No, the JMM specification is not vague. Abridged, it provides a minimum set of guarantees in terms of data visibility between threads -happens-before rules- that the application programmer can expect. Think of it as an abstraction layer that portrays an uniform view of the myriad of hardware configurations on which the JVM runs -e.g. cache coherence strategies-, thus relieving the programmer from the burden of knowing the nuts and bolts of the target system for which its code is intended.