0 Replies Latest reply: Mar 25, 2011 4:19 PM by 850501 RSS

    Is synchronization - apart from the queueing - the same in the RTSJ?

    850501
      Hi,

      I'm just learning real-time java so you'll have to excuse me if any of my questions are stupid.

      To add a little context: I first scoured the book 'Java Concurrency in Practice' to get a thorough understanding of java concurrency before starting to learn real-time java, primarily through the Sun book 'Real-Time Java Programming with Java RTS' but also through online sources.

      Well, the problem is that I thought I had gained a clear understanding of java synchronization from 'Java Concurrency in Practice' but after studying code from 'Real-Time Java Programming with Java RTS' and reading the RTSJ and other online sources of real-time java code I am left confused and wondering if: a) Some of this code is not thread-safe (I am unable to locate an errata list for the Java RTS book so I cannot know if there are recognised errors in the code from that book); b) I haven't managed to understand java concurrency as well as I had hoped; or c) There are some differences relating to synchronization (apart from queueing) in the RTSJ that I have not been made aware of.

      1) WaitFreeWriteQueue and WaitFreeReadQueue: The RTSJ specification says that the non-blocking read or write is done without synchronization but makes no mention of the issue of memory visibility for safe publication of the object from one thread to another. Do we just assume that the non-blocking read or write has the memory semantics of a volatile read/write? Furthermore - though this is actually a queueing question - I don't understand how this avoids 'the risk of a NoHeapRealtimeThread incurring Garbage Collector latency due to priority inversion avoidance management'(RTSJ spec.). As I understand it, a lower-priority thread synchronizing on an object lock that a higher priority thread is waiting for, inherits the higher priority of the waiting thread. At which point surely it would have a higher priority than the GC and so couldn't be pre-empted by it. What am I missing here?

      2) In Listing 8-18 of 'Real-Time Java Programming with Java RTS': There is a shared (non-volatile) Boolean variable called 'updated' that is initialised to 'true'. A Runnable is passed to the constructor of an AsyncEventHandler so that it is run when an event is fired. This Runnable, in its run() method, synchronizes on the 'updated' variable and within that synchronized block, changes its value like so:
      synchronized ( updated ) {
          if ( updated ) {
              updateClients(price);
               updated = false;
              sendNextUpdate = false;
          }
          else {
              sendNextUpdate = true;
          }
      }
      while another thread synchronizes on the same Boolean object and also changes its value like so:
      synchronized ( updated ) {
          System.out.println("Listener: update=" + update);
          price += update;
          updated = true;
          if ( sendNextUpdate )
              conflater.run();
      }
      Can this really be thread-safe? The object being synchronized on - being an immutable wrapper class - changes it's reference and System.identityHashcode() when it's value is changed between true and false. This would mean that the two threads wouldn't be able to acquire the monitor of the same object and so correctly synchronize, no? Perhaps this would work if the Boolean reference 'update' was declared as volatile?

      3) The documentation for RealtimeThread.waitForNextPeriod() doesn't specify whether it releases any locks it might be holding. Since there is an example of this method being called while holding a lock in the Java RTS book, I assume it does, right?


      Thanks in advance for any help received.

      Mike

      Edited by: user3954405 on 25-Mar-2011 14:17