Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #39167
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Thread and synchonized question |
| Date | 2019-09-30 17:07 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <qmtqqm$oln$1@dont-email.me> (permalink) |
| References | <55e14769-2ee7-4e11-8f66-69c1b7bf0241@googlegroups.com> |
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.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web