Forums Register Login

synchronized block vs. synchronized method?

+Pie Number of slices to send: Send
I am curious what the fundamental differences are between a synchronized block and a synchronized method. Example below.

// synchronized block
public void MyClearMethod() {
synchronized(CollectionObj) { // object is not 'this'
CollectionObj.clear(); // clears collection
CollectionObj.notify();
}
}

// synchronized method
public void synchronized MyClearMethod() {
CollectionObj.clear();
CollectionObj.notify();
}
+Pie Number of slices to send: Send
See this Post for a similar discussion.
+Pie Number of slices to send: Send
Well, I'm not an expert by any means but threads is a very interesting topic to me. A couple of thoughts I have on that... and I'd appreciate any comment on these as it will further my understanding.

1) Method locks. When a method is synchronized then the lock is applied to the instance of the object in non-static context, and to the Class itself in static context. But in both cases, when you lock the method, you lock all other threads out of any and all synchronized methods (well...the same context, static or non-static being kept in mind) and they are locked out for the duration of the method, including any method calls invoked from within this method. That adds up to increased time spent "thumb-twiddling" by waiting threads. How much of that method's code really genuinely NEEDS to be done under lock protection? If you code well and make use of local variables you might be able to minimize the area that needs to be locked but, again, with method locks you lock the entire object(in non-static)/class(in static) for the duration of the method.

2) Block locks. Synchronizing a block of code allows two things: a) finer granularity of the area locked, and, b) selection/specification of a lock object rather than "this"(non-static) or the class(in static). The finer granularity part means that you only lock the code region that really needs to be locked. That means you have to code with a finer eye (any instance, static variables are treated as read-only, the working variables are local(on the stack ... so each thread has it's own), but that means threads can at least be concurrently active through portions of the called methods and contention for locks is minimized to just the required areas. Selection of a lock object means that you can have several locks protecting a different resource/set of resources. IN other words ... on any given thread execution though a particular method the resource might need to be synchronized, but, if the methods utilize different resources than those used by another method.... use a different lock. Any simple Object can be a lock.

3) THIS one may draw some heat.
The Sierra/Bates SCJP warns against mixing static and non-static resources under method locks and I agree with that. But who hasn't come up with cases where you needed to do something that wasn't quite savory but you had a case for doing it that way? Well... if you instantiate an object with a static referrence and use it only for block synchronized locking.. it seems to me that as long as the code is written properly, both static and non-static resources could be synchronized by simply using that statically referenced object as the lock. I'll admit that I have not done any prototyping but it seems reasonable.
Look ma! I'm selling my stuff!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 19334 times.
Similar Threads
Synchonized
Plz Tell Ans
Threads: Doubt
Client- Server chat application
synchronized
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 09:44:02.