Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Thread and synchonized question Date: Mon, 30 Sep 2019 17:07:32 -0400 Organization: A noiseless patient Spider Lines: 65 Message-ID: References: <55e14769-2ee7-4e11-8f66-69c1b7bf0241@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 30 Sep 2019 21:07:34 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="a7a45dc9fca013abd03291e89ab441b4"; logging-data="25271"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Mv9L7bdlfm4uveYaC3o3S" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cancel-Lock: sha1:WxPnQ1SA1oPC6lHDWk1nzvA+oeE= In-Reply-To: <55e14769-2ee7-4e11-8f66-69c1b7bf0241@googlegroups.com> Content-Language: en-US Xref: csiph.com comp.lang.java.programmer: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.