Intrinsic locks - static synchronized method

I am trying to understand the "static synchronized threads" - by theory when such a thread is invoked, it has to obtain a intrinsic lock on all the static variables. I wrote a sample program, but it is not giving me the desired results.
I have 3 threads, t1, t2, t3. t1 calls a static synchronized method crazy(), where i am using static int i. t2 and t3 calls a void function f2() and f3() which just prints i. Now i put a sleep in synchronized method crazy. I am expecting t1 to start and print i and go to sleep for 10 secs, release i and then t2 and t3 starts since crazy() holds an intrinsic lock on i. But the program calls t2 and t3 even if crazy puts the thread to sleep. What happend to the intrinsic lock on i ??
class RunnableThread implements Runnable{
static String i;
void f2() {
RunnableThread.i = "Two";
System.out.println(RunnableThread.i);
void f3() {
this.i = "three";
System.out.println(this.i);
static synchronized void crazy() {
try {
i = "One";
System.out.println(i);
Thread.sleep(10000);
System.out.println("Sleep done");
catch (Exception e ) {
e.printStackTrace();
public void run() {
System.out.println("Thread Name: " + Thread.currentThread().getName());
if (Thread.currentThread().getName().equals("two"))
f2();
} else if (Thread.currentThread().getName().equals("three"))
f3();
else if (Thread.currentThread().getName().equals("one"))
RunnableThread.crazy();
public static void main(String args[]) {
System.out.println("SOP from main");
RunnableThread rt1 = new RunnableThread();
RunnableThread rt2 = new RunnableThread();
RunnableThread rt3 = new RunnableThread();
Thread t1 = new Thread(rt1, "one");
t1.start();
Thread t2 = new Thread(rt2, "two");
t2.start();
Thread t3 = new Thread(rt3, "three");
t3.start();

lavanya.km wrote:
I am trying to understand the "static synchronized threads"Never heard of it. You might want to clarify your terminology.
- by theory when such a thread is invoked, it has to obtain a intrinsic lock on all the static variables. Nope. Doesn't happen.
I wrote a sample program,Ah, I see. You're creating synchronized static methods. Those do not even come close to "obtaining an intrinsic lock on all the static variables," even if there were such a thing as an "intrinsic lock," which there isn't. A synchronized method is just shorthand for enclosing the entire body in a sync block. In the case of a non-static method, it syncs on the "this" object. In the case of a static method, it syncs on the Class object for the class where the method is declared.
In no case does anything sync on "all the variables," static or not.

Similar Messages

  • Multiple static synchronized methods locking the same object ?

    If I have multiple static synchronized methods in a class will all the methods lock on the same (Class) object ? I guess the answer to this would be yes. In that case is it possible achieve synchronization without an object ie code level synchronization ? If yes, how ?

    If I have multiple static synchronized methods in a
    class will all the methods lock on the same (Class)
    object ? I guess the answer to this would be yes. In
    that case is it possible achieve synchronization
    without an object ie code level synchronization ? If
    yes, how ?There is nothing special about static synchronized methods vs. any other synchronization. It's just shorthand for syncing on the Class object for that class. The effects of synchronization are identical no matter what you sync on.
    There's no way to achieve synchronization without an object. Synchronizing always obtains an object's lock. In the case of static synced methods, the object whose lock we obtain is the Class object for that class. As far as syncing goes, it's just another object.
    There is no such thing as "code level synchronization" vs. any other kind. All syncing occurs in your Java code over blocks of code. For synced methods, those blocks are the entire respective method bodies.
    Having said all that, I have no idea what you're really after or what you're trying to achieve.

  • Static synchronized methods VS non-static synchronized methods ??

    what is the difference between static synchronized methods and non-static synchronized methods as far as the behavior of the threads is concerned? if a thread is in static synchronized method can another thread access simple (ie. non static) synchronized methods?

    javanewbie80 wrote:
    Great. Thanks. This whole explanation made a lot of sense to me.Cool, glad I was able to help!
    Probably I was just trying to complicate things unnecessarily.It's a classic case of complexity inversion. It seems simpler to say something like "synchronization locks the class" or "...locks the method" than to give my explanation and then extrapolate the implications. Just like the seemingly simpler, but incorrect, "Java passes objects by reference," vs. the correct "Java passes references by value," or Java's seemingly complex I/O vs. other languages' int x = readInt(); or whatever.
    In the seemingly complex case, the primitive construct is simpler, but the higher level construct requires more assembly or derivation of the primitive constructs, making that case seem more complicated.
    Okay, I just re-read that, and it seems like I'm making no sense, but I'll leave it, just in case somebody can get some meaning out of it. :-)

  • Static synchronized method

    hi,
    I am unable to understand the concept of static synchronized method.
    A non-static synchronized method gets lock on this object before entering into the method. But how this is valid for static method.
    thanks in advance

    hi,
    I am unable to understand the concept of static
    atic synchronized method.
    A non-static synchronized method gets lock on
    this object before entering into the method.
    But how this is valid for static method.
    thanks in advanceIt locks the YourClassName.class object.

  • Calling static synchronized method in the constructor

    Is it ok to do so ?
    (calling a static synchronized method from the constructor of the same class)
    Please advise vis-a-vis pros and cons.
    regards,
    s.giri

    I would take a different take here. Sure you can do it but there are some ramifications from a best practices perspective. f you think of a class as a proper object, then making a method static or not is simple. the static variables and methods belong to the class while the non-static variables and methods belong to the instance.
    a method should be bound to the class (made static) if the method operates on the class's static variables (modifies the class's state). an instance object should not directly modify the state of the class.
    a method should be bound to the instance (made non-static) if it operates on the instance's (non-static) variables.
    you should not modify the state of the class object (the static variables) within the instance (non-static) method - rather, relegate that to the class's methods.
    although it is permitted, i do not access the static methods through an instance object. i only access static methods through the class object for clarity.
    and since the instance variables are not part of the class object itself, the language cannot and does not allow access to non-static variables and methods through the class object's methods.

  • Static synchronized methods

    Hi
    Why dont we declare static methods synchronized especially if they are doing some complex calculation on some passed arguments ?
    thanks
    ali

    lucky_ali80 wrote:
    Hi guys
    Thanks for your quick replies. But i am still a bit confused.Then you're making it more complicated than it is.
    You synchronize a block of code when you want to makes sure only one thread at a time can obtain a given lock for that block of code. You declare an instance (non-static) method synchronized as a shorthand for synchronizing the block that is its body on this, and you declare a class (static) method synchronized as a shorthand for synchronizing its body on the Class object for that class.
    >
    For e.g my static function looks some thing like the one below:
    public class MyClass
    public static int computeSomething ( int a , int b)
    // a number of lines of complex computation on a and b
    return result.
    Now Say its a webserver running with object1, object2, 3...10 of the same type being maintained by the server. (Not threads but objects)
    say all these objects simultaneously call my static function with their respective arguments.
    Would this cause any synchronization issues??No. As I said in my first reply, every thread has its own copy of local variables. This includes method parameters. Each thread has its own a and b here.
    Now, if you're using some other data besides a and b, and if that data is shared among multiple threads, then you may have an issue. We can't say for sure because there are many different possible scenarios.
    Edited by: jverd on Feb 10, 2009 11:58 AM

  • Use of 'static' keyword in synchronized methods. Does it ease concurrency?

    Friends,
    I have a query regarding the use of 'synchronized' keyword in a programme. This is mainly to check if there's any difference in the use of 'static' keyword for synchronized methods. By default we cannot call two synchronized methods from a programme at the same time. For example, in 'Program1', I am calling two methods, 'display()' and 'update()' both of them are synchronized and the flow is first, 'display()' is called and only when display method exits, it calls the 'update()' method.
    But, things seem different, when I added 'static' keyword for 'update()' method as can be seen from 'Program2'. Here, instead of waiting for 'display()' method to finish, 'update()' method is called during the execution of 'display()' method. You can check the output to see the difference.
    Does it mean, 'static' keyword has anything to do with synchronizaton?
    Appreciate your valuable comments.
    1. Program1
    public class SynchTest {
         public synchronized void display() {
              try {
                   System.out.println("start display:");
                   Thread.sleep(7000);
                   System.out.println("end display:");
              } catch (InterruptedException e) {
                   e.printStackTrace();
         public synchronized void update() {
              try {
                   System.out.println("start update:");
                   Thread.sleep(2000);
                   System.out.println("end update:");
              } catch (InterruptedException e) {
                   e.printStackTrace();
         public static void main(String[] args) {
              System.out.println("Synchronized methods test:");
              final SynchTest synchtest = new SynchTest();
              new Thread(new Runnable() {
                   public void run() {
                        synchtest.display();
              }).start();
              new Thread(new Runnable() {
                   public void run() {
                        synchtest.update();
              }).start();
    Output:
    Synchronized methods test:
    start display:
    end display:
    start update:
    end update:
    2. Program2
    package camel.java.thread;
    public class SynchTest {
         public synchronized void display() {
              try {
                   System.out.println("start display:");
                   Thread.sleep(7000);
                   System.out.println("end display:");
              } catch (InterruptedException e) {
                   e.printStackTrace();
         public static synchronized void update() {
              try {
                   System.out.println("start update:");
                   Thread.sleep(2000);
                   System.out.println("end update:");
              } catch (InterruptedException e) {
                   e.printStackTrace();
         public static void main(String[] args) {
              System.out.println("Synchronized methods test:");
              final SynchTest synchtest = new SynchTest();
              new Thread(new Runnable() {
                   public void run() {
                        synchtest.display();
              }).start();
              new Thread(new Runnable() {
                   public void run() {
                        synchtest.update();
              }).start();
    Output:
    Synchronized methods test:
    start display:
    start update:end update:
    end display:

    the synchronized method obtain the lock from the current instance while static synchronized method obtain the lock from the class
    Below is some code for u to have better understanding
    package facado.collab;
    public class TestSync {
         public synchronized void add() {
              System.out.println("TestSync.add()");
              try {
                   Thread.sleep(2000);
              } catch (InterruptedException e) {
                   e.printStackTrace();
              System.out.println("TestSync.add() - end");          
         public synchronized void update() {
              System.out.println("TestSync.update()");
              try {
                   Thread.sleep(2000);
              } catch (InterruptedException e) {
                   e.printStackTrace();
              System.out.println("TestSync.update() - end");          
         public static synchronized void staticAdd() {
              System.out.println("TestSync.staticAdd()");
              try {
                   Thread.sleep(2000);
              } catch (InterruptedException e) {
                   e.printStackTrace();
              System.out.println("TestSync.staticAdd() - end");
         public static synchronized void staticUpdate() {
              System.out.println("TestSync.staticUpdate()");
              try {
                   Thread.sleep(2000);
              } catch (InterruptedException e) {
                   e.printStackTrace();
              System.out.println("TestSync.staticUpdate() - end");
         public static void main(String[] args) {
              final TestSync sync1 = new TestSync();
              final TestSync sync2 = new TestSync();
              new Thread(new Runnable(){
                   public void run() {
                        sync1.add();
              }).start();
              new Thread(new Runnable(){
                   public void run() {
                        sync2.update();
              }).start();
              try {
                   Thread.sleep(3000);
              } catch (InterruptedException e) {
                   e.printStackTrace();
              new Thread(new Runnable(){
                   public void run() {
                        sync1.staticAdd();
              }).start();
              new Thread(new Runnable(){
                   public void run() {
                        sync2.staticUpdate();
              }).start();
    }

  • Which object's monitor does a synchronized method acquire?

    from the Java Tutorial for concurrency programming:
    " When a thread invokes a synchronized method, it automatically acquires the intrinsic lock _for that method's object_ and releases it when the method returns. The lock release occurs even if the return was caused by an uncaught exception. "
    what exactly does this mean?
    do synchronized methods acquire the monitors for objects of type: java.lang.reflection.Method
    please consider this code:
    public class Foo {
      private int counter = 0;
      public synchronized void incriment() { counter++; }
      public synchronized void decriment() { counter--; }
    Foo f = new Foo();
    Class[] sig = new Class[0];
    Method m = f.getClass().getMethod("incriment", sig);
    // ok. so "m" is the relevant method object.
    f.incriment(); // <-- is the monitor for "m" ,
                          // or the monitor for "f", acquired?
    .......my reading of the Concurrency Tutorial is that synchronized methods use the monitors of java.lang.reflection.Method objects?
    and thus, Foo is not thread safe, right?
    however, this simple change makes Foo thread-safe?
    public class Foo {
      private volatile int counter = 0; // "volatile"
      public void incriment() { counter++; }
      public void decriment() { counter--; }
    }thanks.
    Edited by: kogose on Feb 23, 2009 7:13 PM

    tensorfield wrote:
    jverd wrote:
    tensorfield wrote:
    kogose wrote:
    what exactly does this mean?It means you're complicating things.
    If a method is synchronized, it is. You don't need to go beyond that. The method is synchronized.Not true. You have to know what it means for a method to be synchronized. Often people come in with the erroneous impression that it somehow prevents you from using or accessing the object in any other thread.It's very simple. If a synchronized method is called at the same time from many threads only one call will be executed at a time. The calls will be lined up and performed one after the other in sequence.
    AND because synchronization is on a per object basis, when one synchronized method is being called from one thread, all synchronized methods of that same object are blocked for calling from other threads.
    Simple as that.No, it's not that simple, and as stated, that is not correct. In particular, you didn't mention that for an instance method, all the various threads have to be trying to call instance methods on the same object in order for execution to be sequential.
    You really can't understand Java's syncing without understanding how it relates to locks, and what it means for a method to be synchronized in terms of which lock it acquires.
    Edited by: jverd on Feb 25, 2009 2:47 PM

  • Doubt: About synchronized methods?

    Hi,
    Can any one let me know, Is there any difference between static and non-static synchronized methods? If yes, what is the difference?

    One is static and one isn't. What did you think?
    As I recall, non-static methods lock on the object, whereas static methods lock on the class object, if that's what you're wondering about.

  • Prblem calling synchronized method from onMessage

    Hi friends,
    I am trying to call a synchronized method "X" from onMessage method in MDB.
    I dont see any effect of synchronization....
    do i need to make the "X" method static synchronized??
    or else is there any other way ?
    I need ur help

    Hi,
    MDBs are not single threaded as messages are concurrently processed. You did not get any synchronisation as all your MDB instances (threads) are accessing a different instance of your object. But however, if you use a static synchronized method then all your MDB instances will be synchronized on the same object and that should have the expected behaviour.
    Arnaud

  • What is a lock in a synchronized method ??

    Greetings,
    I have a synchronized reset method whose job is to reset every variable i am using in that class.. its a synchronized method so when i am doing the reset stuff, no other method in that class can update that variable. But someone told me i need to also put lock inside the reset method and check for the lock everywhere where i update those variables ( So that variable doesn't update itself and lose its value as reset would be resetting that variable.) How do i lock all these variables in that reset method and how do i check for the lock where i would be updating that variable.
    Example: Psedo code
    class {
    int a =0;
    int b = 0;
    method update {
    a = 5;
    method update1{
    b = 6;
    synchronized method reset{
    a =0;
    b = 0;

    javanewbie83 wrote:
    Greetings,
    I have a synchronized reset method whose job is to reset every variable i am using in that class.. its a synchronized method so when i am doing the reset stuff, no other method in that class can update that variable. But someone told me i need to also put lock inside the reset method and check for the lock everywhere where i update those variables ( So that variable doesn't update itself and lose its value as reset would be resetting that variable.) How do i lock all these variables in that reset method and how do i check for the lock where i would be updating that variable.You don't need to "check" for the lock. When you have a synchronized block or method, the synhcronized keyword tells the VM to stop executing that thread until it can attain the object's lock, then give the object's lock to that thread, and then take it back when the thread leaves the synchronized block (or calls wait()). It's all automatic.
    Note that you'll need to synchronize not only write access to the variable(s) in question, but read access also, in order to ensure that reader threads see the values written by writers.

  • Synchronizing methods and a static main method

    I have a class with a static main method, calling 3 different jdbc updates.
    I want to make sure this is thread safe when called for various clients.
    It's goes:
    args[0] = clientI
    update 1:update field1 where clientid = client1
    update 2:update field2 where clientid = client1
    update 3:update field3 where clientid = client1I assume I am in jeopardy of mixing up my data?
    I don't think I can synchronize a main method, nor would it do any good to synchronize the class?
    Should I break the updates into methods, then synchronize them, or synchronize parts of the code?
    you opinion would help greatly.

    You haven't provided enough information.
    Are those updates occurring sequentially? Then it's threadsafe.
    Are they running in different threads? Then to make them threadsafe you'll need proper synchronization, or a database transaction.
    Of course, looking at those particular updates, I don't see any reason why you'd need to worry about thread safety. They look to be independent of each other. Or perhaps you meant you need them to be atomic? That is, any query will see either the old values of all three fields, or the new values of all three fields. Nobody will be able to see the new values for fields 1 and 2, but the old value for field 3. If that's the case, then those three updates need to be in a database transaction.

  • Range of synchronized method?

    Hi,
    If you have a synchronized method, which calls another method, is that other method also synchronized?
    protected synchronized void doSomething() {
        // ... some coding
        heavyNumberCrunching()
        // ... some more coding
    protected void heavyNumberCrunching() {
        // ... even more coding
    }Additions:
    1. only doSomething() calls heavyNumberCrunching()
    2. heavyNumberCrunching() reads from/writes to collections, that can be accessed by other thread. Will access to these collections (not necessarily a Vector or Hashtable) be restricted when heavyNumberCrunching is crunching away?
    Just wondering.
    Abel

    spoon_ wrote:
    Abel wrote:
    If you have a synchronized method, which calls another method, is that other method also synchronized?yes, This is incorrect.
    the lock is held from when the method begins to when it endsWhile it is true that the lock is held until the synchronized method ends, that lock does not prevent access to unsynchronized methods by other threads.
    An example:
    =============
    public class Crunch {
        Crunch() {
            Thread[] aTeam = new Thread[10];
            for (int i = 0; i < 10; i++) {
                aTeam[i] = new Thread(new Runnable() {
                    public void run() {
                        doSomething();
                }, "A Team Thread " + i);
                aTeam.start();
    Thread[] bTeam = new Thread[10];
    for (int i = 0; i < 10; i++) {
    bTeam[i] = new Thread(new Runnable() {
    public void run() {
    heavyNumberCrunching();
    }, "B Team Thread " + i);
    bTeam[i].start();
    public synchronized void doSomething() {
    heavyNumberCrunching();
    public void heavyNumberCrunching() {
    System.out.println("Crunching on thread: " + Thread.currentThread().getName());
    try {
    Thread.sleep(2000);
    } catch (InterruptedException ie) {
    ie.printStackTrace();
    System.out.println("Done crunching on thread: " + Thread.currentThread().getName());
    public static void main(String[] args) {
    new Crunch();
    The A Team threads all access the heavyNumberCrunching() method via the synchronized doSomething() method. The B Team threads call heavyNumberCrunching() directly.
    Here's some output from a run on my quad core machine:
    Crunching on thread: A Team Thread 0
    Crunching on thread: B Team Thread 0
    Crunching on thread: B Team Thread 1
    Crunching on thread: B Team Thread 2
    Crunching on thread: B Team Thread 3
    Crunching on thread: B Team Thread 4
    Crunching on thread: B Team Thread 5
    Crunching on thread: B Team Thread 6
    Crunching on thread: B Team Thread 7
    Crunching on thread: B Team Thread 9
    Crunching on thread: B Team Thread 8
    Done crunching on thread: B Team Thread 5
    Done crunching on thread: B Team Thread 4
    Done crunching on thread: B Team Thread 9
    Done crunching on thread: B Team Thread 3
    Done crunching on thread: B Team Thread 7
    Done crunching on thread: B Team Thread 1
    Done crunching on thread: B Team Thread 2
    Done crunching on thread: A Team Thread 0
    Done crunching on thread: B Team Thread 8
    Done crunching on thread: B Team Thread 6
    Done crunching on thread: B Team Thread 0
    Crunching on thread: A Team Thread 9
    Done crunching on thread: A Team Thread 9
    Crunching on thread: A Team Thread 8
    Done crunching on thread: A Team Thread 8
    Crunching on thread: A Team Thread 7
    Done crunching on thread: A Team Thread 7
    Crunching on thread: A Team Thread 6
    Done crunching on thread: A Team Thread 6
    Crunching on thread: A Team Thread 5
    Done crunching on thread: A Team Thread 5
    Crunching on thread: A Team Thread 4
    Done crunching on thread: A Team Thread 4
    Crunching on thread: A Team Thread 3
    Done crunching on thread: A Team Thread 3
    Crunching on thread: A Team Thread 2
    Done crunching on thread: A Team Thread 2
    Crunching on thread: A Team Thread 1
    Done crunching on thread: A Team Thread 1Notice while Team A Thread 1 is crunching, most of the B Team threads start and finish crunching. Nothing prevents a call to an unsynchronized block of code, even if that code is called from a synchronized block.
    Jim S.

  • Optimizing synchronized method?

    A couple of other threads got me to thinking about a bit of code I commonly use. Is a synchronized method really expensive enough to make this modification warranted?
    Original method:
      private static Manager theManager = null;
      public static synchronized getManager() {
        if (theManager != null) return theManager;
        theManager = new Manager();
        return theManager;
      }Optimized version:
      private static Manager theManager = null;
      public static getManager() {
        if (theManager != null) return theManager;
        synchronized (theManager) {
          if (theManager != null) return theManager;
          theManager = new Manager();
        return theManager;
      }The intent is that since theManager gets created only rarely (i.e. once at the beginning of the session) all the subsequent invocations do not need to execute the synchronized logic. Is this worth it?

    The article states that the use of the volatile keyword fixes the problem, at least for later versions Java. Is that not right?For JDK 1.5 and above, perhaps. For JDK 1.4 and below, no.
    However, I am more interested in the solution presented by a link elsewhere in that article:
    http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom
    That method solves the problem and no synchronized keyword is needed at all.That's true. However, follow the [double-checked locking|http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html] link in that article, to actually understand what's going on. And pay particular attention to the part that says For most applications, the cost of simply making the getHelper() method synchronized is not high. You should only consider this kind of detailed optimizations if you know that it is causing a substantial overhead for an application.
    And finally: you do realize that singleton is almost never necessary, introduces tight coupling into your program, and makes it difficult to test. Right?

  • Synchronized method not preventing concurrent access

    Hi
    I have 3 classes, T (a Runnable), TRunner (instantiates and starts a thread using T), and Sync (with one synchronized method, foo).
    The problem is that foo is entered concurrently by different threads at the same time. How so?
    T.java:
    import java.util.Calendar;
    class T implements Runnable
       private String name;
       public T(String name)
         this.name = name;
       public void run()
          Thread.currentThread().setName(name);
          Sync s = new Sync();
          System.out.println(Calendar.getInstance().getTime() + ".....Running " + Thread.currentThread().getName());
          s.foo(name);
    }TRunner.java:
    class TRunner
       public static void main(String args[])
           T tx = new T("x");
           T ty = new T("y");
           T tz = new T("z");
           Thread t1 = new Thread(tx);
           Thread t2 = new Thread(ty);
           Thread t3 = new Thread(tz);
           t1.start();
           t2.start();
           t3.start();
    }Sync.java:
    import java.util.Calendar;
    class Sync
       public synchronized void foo(String threadname)
              System.out.println(Calendar.getInstance().getTime() + ":" + threadname + "....entering FOO");
              try
                   Thread.sleep(5000);
              catch (InterruptedException e)
                   System.out.println("interrupted");
              System.out.println(Calendar.getInstance().getTime() + ":" + threadname + "....leaving FOO");
    }Console output:
    C:\javatemp>java TRunner
    Mon Apr 09 15:35:46 CEST 2007.....Running x
    Mon Apr 09 15:35:46 CEST 2007:x....entering FOO
    Mon Apr 09 15:35:46 CEST 2007.....Running y
    Mon Apr 09 15:35:46 CEST 2007:y....entering FOO
    Mon Apr 09 15:35:46 CEST 2007.....Running z
    Mon Apr 09 15:35:46 CEST 2007:z....entering FOO
    Mon Apr 09 15:35:51 CEST 2007:x....leaving FOO
    Mon Apr 09 15:35:51 CEST 2007:y....leaving FOO
    Mon Apr 09 15:35:51 CEST 2007:z....leaving FOO
    C:\javatemp>Thanks in advance.

    Only for static methods. For instance methods, the lock >is the object.You are absolutely right.
    The Class object is no different from any other object. >"Entire" Class object makes no sense.What I wanted to say is that it's better to synchronize on the object we want to protect from concurrent access rather than on the entire class or instance object.
    "Efficiency" is not altered by locking on a Class object vs. >any other object.I studied that it's better to synchronize on the objects we want to protect instead of the entire instance or class object. If one declares a method as synchronized, it means that other threads won't be able to access other synchronized methods for the same object, even if the two weren't in conflict. That was explained as a performance penalty.
    >
    Or when one or more threads may modify it and one or
    more may read it.
    Yep, sure.
    >
    No, they're not.
    You are absolutely right. What I wanted to say is that local variables are unique per thread.
    >
    Local variables are unique per thread, but that's NOT
    atomicity.Sorry for any confusion
    Message was edited by:
    mtedone

Maybe you are looking for

  • How to deal with the old instances of any class?

    Hi, I have a doubt regarding the old instances of any class. Currently i am designing a game in java swing. I have a new game button, which creates a new game instance of the game class. There might be conditions that the old game is finished and use

  • Transfer from a 3GS to 5, but keep the 3GS for all but Phone use

    I have ordered an iPhone 5, currently have a 3GS. I plan to backup everything on the 3GS and then restore to the iPhone 5 using iTunes.  Will I still be able to synch my 3GS when I plug it into iTunes to keep my applications etc. up to date? Will iTu

  • Setting Markers in Log & Transfer window

    Hi All Anyone know a trick/plug-in that will enable me to set markers while I am setting my In's and Out's in the Log & Transfer Window before I 'Add Clip to Queue'? I would like to set markers indicating the interesting moments in the footage. cheer

  • ADSL2+ not activated on my line.

    Hi, could someone please activate ADSL2+ on my line. I should be able to get 13-14Mbps on this line, but am capped at 8Mbps with 512k upload. I have a HH 3 (black) Hindhead telephone exchange Thanks. Pauline. Line state: Connected Connection time: 0

  • ITunesSetup(1). exe is not a valid Win32 application???

    when I try to download the latest iTunes version. 10.6.3 I get this fault from windows. Never had this before on previous udates. Any help? thanks.