3 ms·

>you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there'

by ddeck 13y ago

>you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there's no guarantee that the parent thread actually executes before the child thread There are definitely some surprising outcomes from the JMM, but I'm pretty sure this isn't one of them. If I recall correctly, starting a thread automatically synchronizes the current thread with the first thing the child thread does, without any explicit synchronization. So anything done prior to that point in the parent thread will be visible in the child.

yebyen 13y ago
I do not have the code here to show you, but if I am exaggerating it's a small fib. Maybe the child thread was created some time before it was started, and the initialization happened some time between those events. It was an example that a friend was working for a class, and as they often do, came to me for help on why it wasn't behaving as expected. I looked at it and I could see the problem, "you don't have any locks shared between parent and child." We added a lock, synchronized it once in each thread, and the problem went away. That's definitely a surprising outcome for anyone who is accustomed to procedural programming.
- ddeck 13y ago
  The implicit synchronization happens at the point the child thread is started, regardless of when it was allocated. Perhaps it was already started prior to the initialization, in which case some form of explicit synchronization would be required to ensure visibility. FYI, the relevant section of the JLS is 17.4.4: "An action that starts a thread synchronizes-with the first action in the thread it starts." [1]. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.4 http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html...
  - yebyen 13y ago
    I can guarantee you the class was not offered the option of using Java 7. I'll take your word for it if you say this is not a new feature, but I'm sure the story went just about how I've laid it out.
  - yebyen 13y ago
    This sounds more like what we experienced: > The write of the default value (zero, false or null) to each variable synchronizes-with the first action in every thread. Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values. I can't get that to jibe in my memory though against: > The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated. > T2 may accomplish this by calling T1.isAlive() or T1.join(). If we were looking into the threads, it would have been obvious that we should wait for the thread to finish before expecting to find a completed value in it other than the default. That's not what happened. It's unfortunate that I didn't get a copy of the code in question, because it was a genuine idiosyncrasy in Java and by the time I got around to asking my friend for a copy, he had already rewritten his code in a different way that didn't hit the same bug. Didn't use revision control, got his degree didn't care to repeat the same miserable exercises, now probably hacking ruby in his day job like me (except I promise I'm using revision control.)

by ddeck 13y ago

yebyen 13y ago

I do not have the code here to show you, but if I am exaggerating it's a small fib. Maybe the child thread was created some time before it was started, and the initialization happened some time between those events. It was an example that a friend was working for a class, and as they often do, came to me for help on why it wasn't behaving as expected. I looked at it and I could see the problem, "you don't have any locks shared between parent and child." We added a lock, synchronized it once in each thread, and the problem went away. That's definitely a surprising outcome for anyone who is accustomed to procedural programming.

ddeck 13y ago
The implicit synchronization happens at the point the child thread is started, regardless of when it was allocated. Perhaps it was already started prior to the initialization, in which case some form of explicit synchronization would be required to ensure visibility. FYI, the relevant section of the JLS is 17.4.4: "An action that starts a thread synchronizes-with the first action in the thread it starts." [1]. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.4 http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html...
- yebyen 13y ago
  I can guarantee you the class was not offered the option of using Java 7. I'll take your word for it if you say this is not a new feature, but I'm sure the story went just about how I've laid it out.
- yebyen 13y ago
  This sounds more like what we experienced: > The write of the default value (zero, false or null) to each variable synchronizes-with the first action in every thread. Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values. I can't get that to jibe in my memory though against: > The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated. > T2 may accomplish this by calling T1.isAlive() or T1.join(). If we were looking into the threads, it would have been obvious that we should wait for the thread to finish before expecting to find a completed value in it other than the default. That's not what happened. It's unfortunate that I didn't get a copy of the code in question, because it was a genuine idiosyncrasy in Java and by the time I got around to asking my friend for a copy, he had already rewritten his code in a different way that didn't hit the same bug. Didn't use revision control, got his degree didn't care to repeat the same miserable exercises, now probably hacking ruby in his day job like me (except I promise I'm using revision control.)