synchronizing for data visibility

Discussion in 'Java' started by MikL, Oct 20, 2004.

  1. MikL

    MikL Guest

    I have an object that is accessed and updated by multiple threads, but the
    application architecture ensures that only one thread at a time will do
    this. As I understand it, I don't need to worry about using "synchronized"
    to prevent concurrent access, but I _do_ need to use "synchronized" when a
    new thread starts using it to ensure it doesn't use out-of-date cached
    values on a multi-processor JVM.

    I'm trying to avoid using synchronized methods:
    1) to avoid the performance hit that I read about everywhere.
    2) a multi-cycle "conversation" can occur between threads, so to avoid
    deadlocks I don't want to synchronize at the API level.
    3) a single API call to the class can internally call dozens of methods,
    each of which accesses properties -- and then I'm faced with dozens of
    synchronized blocks per API call.

    Does this make sense? Is there a better way of doing things?

    Here's a massively simplified illustration of what I'm thinking. The real
    thing is far more complicated, with dozens of properties, and deeply nested
    method calls.

    public class MyClass
    {
    private int fThing;

    // a background thread runs this
    private void publishEvent (...)
    {
    SwingUtilities.invokeAndWait(new Runnable() { ...indirect callback to
    setThing() }.)
    synchronized (this) { /* ensure cache up to date after AWT thread
    access finishes */ }
    }

    // this method is called back from the AWT-Event thread when triggered by
    publishEvent()
    public void setThing (int aValue)
    {
    synchonized(this) { /* ensure have up to date cache */ }
    fThing = aValue;
    // do more stuff
    // possibly call publishEvent() recursively.
    }
    }
     
    MikL, Oct 20, 2004
    #1
    1. Advertising

  2. MikL

    Chris Smith Guest

    MikL wrote:
    > I have an object that is accessed and updated by multiple threads, but the
    > application architecture ensures that only one thread at a time will do
    > this. As I understand it, I don't need to worry about using "synchronized"
    > to prevent concurrent access, but I _do_ need to use "synchronized" when a
    > new thread starts using it to ensure it doesn't use out-of-date cached
    > values on a multi-processor JVM.


    Yes, that's basically true. Whenever you access shared state, you need
    at least one synchronization boundary to ensure that you're accessing
    data from a well-defined point. Furthermore, you need to ensure that at
    the point that you cross the synchronization boundary and afterward
    until you are finished accessing shared state, no other thread is
    actively making changes to the data and all other threads have crossed a
    synchronization boundary since their last modification to the shared
    state. There is, however, no requirement that you necessarily need to
    hold a monitor while accessing (or modifying) shared state.

    What you may be looking for is a reader/writer lock. This would ensure
    at least the level of control that you want, while not preventing
    concurrency between reader threads (thus solving your potential deadlock
    issue). If the writer thread would need to be able to interrupt reader
    threads, though, then you've got a bigger problem, and then you need to
    describe what you actually want prior to looking for an implementation
    (i.e., allowing one thread to access data that another is modifying is
    asking for undefined behavior, so you would need to rethink your goals).

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Oct 20, 2004
    #2
    1. Advertising

  3. MikL

    MikL Guest

    Thank you Chris,

    I can now proceed in confidence that I'm somewhere near the right track. I
    will have a think about reader/writer locks.
     
    MikL, Oct 21, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rog
    Replies:
    1
    Views:
    403
    Eric Marvets
    May 22, 2004
  2. Christopher D. Wiederspan

    Synchronizing ASP.NET Content Across WebFarm

    Christopher D. Wiederspan, Jul 30, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    478
    Yan-Hong Huang[MSFT]
    Aug 1, 2003
  3. Mark Fox

    Synchronizing Code Behind

    Mark Fox, Dec 18, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    448
    Mark Fox
    Dec 19, 2003
  4. Alphonse Giambrone

    Synchronizing Local and Web Data

    Alphonse Giambrone, Aug 11, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    556
    Alphonse Giambrone
    Aug 13, 2004
  5. Replies:
    0
    Views:
    235
Loading...

Share This Page