Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multi thread Memory Visibility inside Synchronized keyword  (Read 4165 times)
0 Members and 1 Guest are viewing this topic.
Offline Mordan

Junior Devvie





« Posted 2016-11-04 11:50:48 »

I am using multiple threads.. To better understand an issue, I need an answer to this rethorical question

I posted it on stack
http://stackoverflow.com/questions/40421491/java-synchronization-and-memory-visibility-is-10-visible-to-other-threads


I have two classes.

One class is just a container for a integer value with get and set synchronized methods.

public class Sync {
   private int dataSync;

   public synchronized int getDataSync() {
       return dataSync;
   }

   public synchronized void setDataSync(int data) {
      dataSync = data;
   }
}

The other classes is similar. It is just a container for a integer value with get and set methods without synchronization.

public class NotSync {

   private int dataNotSync;

   public int getDataNotSync() {
      return dataNotSync;
   }

   public void setDataNotSync(int data) {
      dataNotSync = data;
   }
}

Now my rhetorical question is "is 10 value guaranteed to be visible to all other threads" at the end of the run method.

public class RunSync {

   public static void main(String[] args) {
      RunSync rs = new RunSync();
      rs.run();
   }

   private NotSync dataNS;

   private Sync    dataS;

   public RunSync() {
      dataS = new Sync();
      dataNS = new NotSync();
   }

   public synchronized void run() {
      dataS.setDataSync(45);
      dataNS.setDataNotSync(10);
      //Question A: is 10 value guaranteed to be visible to all other
      //threads when method exits?
      //we are inside a synchronized block aren't we?
      //so all writes must be flushed to main memory
   }
}

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 283
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #1 - Posted 2016-11-04 14:31:56 »

Synchronization has nothing to do with visibility.

The only thing your synchronized methods guarantee is that they can't be called by two different threads at the same time.

You aren't even using threads, so this is a non-issue.

By the way, a rhetorical question is a question that you don't expect an answer to. Maybe you meant hypothetical question?

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline Riven
Administrator

« JGO Overlord »


Medals: 1336
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2016-11-04 14:47:24 »

is 10 value guaranteed to be visible to all other threads?
Nope, it isn't.

The synchronized keyword on the SunSync's run() method also won't help you here. If other threads would, however, synchronize with that RunSync instance, it would be properly synced between threads.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mordan

Junior Devvie





« Reply #3 - Posted 2016-11-04 15:49:41 »

I am trying to wrap my head about it. In my gaming engine, Render State is shared between threads. It is a HEADACHE!

http://gee.cs.oswego.edu/dl/cpj/jmm.html

Visibility is a matter. Threads may update stuff and that stuff stays in the CPU cache and the main memory is not updated.

I bolded the most relevant condition for true visibility. There is of course the volatile keyword as well.

I can't quote it all. The forum won't let me.

Quote
Visibility
Changes to fields made by one thread are guaranteed to be visible to other threads only under the following conditions:

    A writing thread releases a synchronization lock and a reading thread subsequently acquires that same synchronization lock.

    In essence, releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields. While lock actions provide exclusion only for the operations performed within a synchronized method or block, these memory effects are defined to cover all fields used by the thread performing the action.
 
Offline princec

« JGO Spiffy Duke »


Medals: 1012
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2016-11-04 16:15:17 »

Look up "memory barriers".

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 511



« Reply #5 - Posted 2016-11-04 16:28:44 »

Any reader thread will not be guaranteed to see the 10, because they do not really synchronize with the writing thread, and therefore a reading thread may read the value before main() is called.
In other words: The writing and the reading thread must synchronize on the same object in order to establish a happens-before relation (including memory visibility).

Read: https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5
Offline Mordan

Junior Devvie





« Reply #6 - Posted 2016-11-04 18:34:43 »

Any reader thread will not be guaranteed to see the 10, because they do not really synchronize with the writing thread, and therefore a reading thread may read the value before main() is called.
In other words: The writing and the reading thread must synchronize on the same object in order to establish a happens-before relation (including memory visibility).

Read: https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5

I understand that thank you. The happens before. But my concern is the synchronize flushes back to memory.
Imagine there is a field
public volatile boolean was10Written = false;

This field is accessible by any thread

now I modify the method to

 public synchronized void run2() {
      dataNS.setDataNotSync(10);
      was10Written = true;
  }

Will the 10 be visible to other threads checking on was10Written as true?

I want to know if synchronize flushes back to main memory when statement closes. From the answers I got, it seems the answer is no but maybe. It will only be guaranteed to flush back when another lock is aquired. That would make sense from the performance implementation point of view. This prevents the JVM from flushing everytime a sync statement closes.
Offline jonjava
« Reply #7 - Posted 2016-11-04 19:31:43 »

rhetorical

<a href="http://www.youtube.com/v/G2y8Sx4B2Sk?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/G2y8Sx4B2Sk?version=3&amp;hl=en_US&amp;start=</a>

Offline Mordan

Junior Devvie





« Reply #8 - Posted 2016-11-04 19:48:49 »

Look up "memory barriers".

Cas Smiley

This is insane. I am not so sure I can deal with the multi thread engine. I wanted 3 threads. 1 for user input, 1 for simulation, 1 for rendering. And I don't want to put the synchronized keyword on every single method.

I am educating myself right now.

Just a few links for the record.
http://jpbempel.blogspot.be/2013/05/volatile-and-memory-barriers.html

http://lmax-exchange.github.io/disruptor/

Dissecting the Disruptor: Demystifying Memory Barriers
http://mechanitis.blogspot.be/2011/08/dissecting-disruptor-why-its-so-fast.html
Offline Riven
Administrator

« JGO Overlord »


Medals: 1336
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2016-11-04 20:24:45 »

Usually you can greatly simplify inter-thread communication by using queues (like ArrayBlockingQueue).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #10 - Posted 2016-11-05 14:37:28 »

You might want to, specifically, look at SPSC (Single Producer, Single Consumer) Queues and just create queues for each of the interchanges. Nitsan, an awesome guy btw, has a nice set of highly optimized implementations for various situations: https://github.com/nitsanw/JCTools

Pages: [1]
  ignore  |  Print  
 
 

 
ivj94 (583 views)
2018-03-24 14:47:39

ivj94 (47 views)
2018-03-24 14:46:31

ivj94 (374 views)
2018-03-24 14:43:53

Solater (61 views)
2018-03-17 05:04:08

nelsongames (108 views)
2018-03-05 17:56:34

Gornova (150 views)
2018-03-02 22:15:33

buddyBro (693 views)
2018-02-28 16:59:18

buddyBro (91 views)
2018-02-28 16:45:17

xxMrPHDxx (493 views)
2017-12-31 17:17:51

xxMrPHDxx (732 views)
2017-12-31 17:15:51
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!