Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39161 > unrolled thread

Thread and synchonized question

Back to article view | Back to comp.lang.java.programmer

Contents

  Thread and synchonized question mike <mikaelpetterson@hotmail.com> - 2019-09-30 00:32 -0700
    Re: Thread and synchonized question Andreas Leitgeb <avl@logic.at> - 2019-09-30 10:10 +0000
      Re: Thread and synchonized question mike <mikaelpetterson@hotmail.com> - 2019-09-30 04:38 -0700
        Re: Thread and synchonized question Andreas Leitgeb <avl@logic.at> - 2019-09-30 13:48 +0000
    Re: Thread and synchonized question Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-09-30 17:07 -0400
    Re: Thread and synchonized question Arne Vajhøj <arne@vajhoej.dk> - 2019-09-30 19:48 -0400

#39161 — Thread and synchonized question

Hi,

We have class A with method synchronized connect(int) that calls
class B that has synchronized connect() (main thread)

I guess the lock will be on class A?

What if class B and synchronized connect()is called by another thread ( reconnect thread) I guess lock is on class B.

So does this mean that both main and reconnect threads can access the synchronized connect() on class B?

br,

//mike

[toc] | [next] | [standalone]

#39164

mike <mikaelpetterson@hotmail.com> wrote:
> We have class A with method synchronized connect(int) that calls
> class B that has synchronized connect() (main thread)
> I guess the lock will be on class A?

There are some relevant details missing, so there are two options:
A) either or both of the methods are static, or there are two objects
     one of A and one of B that you call the method on: then the locks
     are independent, and main thread just hold both.
B) One of the methods is just a superclass method, and both "synchronize"s
     address the same object, and the main thread holds that one twice.

> What if class B and synchronized connect()is called by another
> thread ( reconnect thread) I guess lock is on class B.

> So does this mean that both main and reconnect threads can access
> the synchronized connect() on class B?

That can be pretty surely excluded in either of the above cases.

[toc] | [prev] | [next] | [standalone]

#39165

Den måndag 30 september 2019 kl. 12:10:52 UTC+2 skrev Andreas Leitgeb:
> mike <mikaelpetterson@hotmail.com> wrote:
> > We have class A with method synchronized connect(int) that calls
> > class B that has synchronized connect() (main thread)
> > I guess the lock will be on class A?
> 
> There are some relevant details missing, so there are two options:
> A) either or both of the methods are static, or there are two objects
>      one of A and one of B that you call the method on: then the locks
>      are independent, and main thread just hold both.
> B) One of the methods is just a superclass method, and both "synchronize"s
>      address the same object, and the main thread holds that one twice.
> 
> > What if class B and synchronized connect()is called by another
> > thread ( reconnect thread) I guess lock is on class B.
> 
> > So does this mean that both main and reconnect threads can access
> > the synchronized connect() on class B?
> 
> That can be pretty surely excluded in either of the above cases.

Hi Andreas,

Thx for replying and helping out to clarify.

Yes I missed to add the information that there are two objects A and B that you call the method on. 

[toc] | [prev] | [next] | [standalone]

#39166

mike <mikaelpetterson@hotmail.com> wrote:
> Den måndag 30 september 2019 kl. 12:10:52 UTC+2 skrev Andreas Leitgeb:
>> mike <mikaelpetterson@hotmail.com> wrote:
>> > We have class A with method synchronized connect(int) that calls
>> > class B that has synchronized connect() (main thread)
>> > I guess the lock will be on class A?
>> 
>> There are some relevant details missing, so there are two options:
>> A) either or both of the methods are static, or there are two objects
>>      one of A and one of B that you call the method on: then the locks
>>      are independent, and main thread just hold both.
>> B) One of the methods is just a superclass method, and both "synchronize"s
>>      address the same object, and the main thread holds that one twice.
>> 
>> > What if class B and synchronized connect()is called by another
>> > thread ( reconnect thread) I guess lock is on class B.
>> 
>> > So does this mean that both main and reconnect threads can access
>> > the synchronized connect() on class B?
>> 
>> That can be pretty surely excluded in either of the above cases.
>
> Hi Andreas,
> Thx for replying and helping out to clarify.
> Yes I missed to add the information that there are two objects A and B that you call the method on. 

I forgot to mention another "caveat":

If the two threads end up calling B.connect() for *different instances*
of B (that means two separate "B" objects), then they can well be within
that method at the same time.

E.g.:
main thread:   new B().connect();
2nd thread:   new B().connect();

Then each thread has its own separate instance, so they can be in
B.connect() at the same time.

In the code of B.connect() you shouldn't rely on the "synchronized"
to access any data outside the respective "this" object.

[toc] | [prev] | [next] | [standalone]

#39167

On 9/30/2019 3:32 AM, mike wrote:
> Hi,
> 
> We have class A with method synchronized connect(int) that calls
> class B that has synchronized connect() (main thread)
> 
> I guess the lock will be on class A?

     The thread will hold two locks, but exactly which two depends
on whether the two connect() methods are `static' or not:

     - The thread first obtains the lock on the A.class object if
       A's connect() is static, or it obtains the lock on a particular
       instance of A if connect() is an instance method.  This lock
       (whichever it is) remains held until A's connect() finishes.

     - When A's connect() calls B's a similar thing happens: The thread
       takes a lock on B.class or on a particular B instance, and holds
       that lock until B's connect() finishes.

     When B's connect() finishes, whether by returning or by throwing
an uncaught exception, the thread releases its B lock.  And then when
A's connect() finishes (either way), the thread releases its A lock.
"First on, last off."

> What if class B and synchronized connect()is called by another thread ( reconnect thread) I guess lock is on class B.

     Let's assume the first thread is still executing B's connect()
method, so it still holds whichever kind of B lock is appropriate.
Then there are three cases:

     - If B's connect() is static, the second thread tries to obtain
       the lock on the B.class object.  The first thread still holds
       that lock, so the second thread pauses until the first thread
       lets go.

     - If B's connect() is an instance method and the second thread
       uses the same B instance as the first, the second thread tries
       to obtain the lock on that B instance.  Again, the first thread
       still holds it, so the second thread waits.

     - If B's connect() is an instance method and the second thread
       uses a different B instance from the first, the second thread
       tries to obtain the lock -- and succeeds, because it's not the
       same lock the first thread is holding.  The second thread sails
       merrily along, and both threads are executing B's connect() at
       the same time -- albeit using different B instances.

> So does this mean that both main and reconnect threads can access the synchronized connect() on class B?

     If B's connect() is an instance method and the two threads use
different B instances, yes.  If it's a static method or if both threads
use the same B instance, no.

     There's a fairly readable tutorial on this stuff at

https://docs.oracle.com/javase/tutorial/essential/concurrency/sync.html

and I think you might be particularly interested in

https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html

-- 
esosman@comcast-dot-net.invalid
Four hundred seventy-eight days to go.

[toc] | [prev] | [next] | [standalone]

#39168

On 9/30/2019 3:32 AM, mike wrote:
> We have class A with method synchronized connect(int) that calls
> class B that has synchronized connect() (main thread)
> 
> I guess the lock will be on class A?
> 
> What if class B and synchronized connect()is called by another thread ( reconnect thread) I guess lock is on class B.
> 
> So does this mean that both main and reconnect threads can access the synchronized connect() on class B?

The key thing to understand is that locks are always on an object.

Two threads trying to lock the same object get impacted.

Two threads trying to lock on different objects are not impacted.

The base syntax is:

synchronized(mylockobject) {
}

But there are two short versions where the object is implicit:

public class C {
     ...
     public synchronized void m() {
	...
     }
     ...
}

means:

public class C {
     ...
     public void m() {
         synchronized (this) {
	    ...
         }
     }
     ...
}

and:

public class C {
     ...
     public static synchronized void m() {
	...
     }
     ...
}

means:

public class C {
     ...
     public static void m() {
         synchronized (C.class) {
	    ...
         }
     }
     ...
}

So look at your code and determine what objects are being locked on.

Arne

PS: Remember that the locking mechanism is only a synchronization
     mechanism. Locking on an objects does not restrict how that object
     can be used by the code.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web