Synchronized methods and virtual threads

[Cay Horstmann]

A bit of history. The motivation for synchronized methods was to bring Per Brinch Hansen's monitor construct to a mainstream language. In a monitor, all methods are synchronized, and you have mechanisms that in Java are called wait/notifyAll. The way this was done in Java is a bit odd. Why have a lock for potentially every instance, when most classes clearly aren't monitors? And why allow public data and a mix of synchronized and non-synchronized methods? And why make the lock be "this" so it leaks to the public? Per Brinch Hansen wasn't amused: "It is astonishing to me that Java 's insecure parallelism is taken seriously by the programming community, a quarter of a century after the invention of monitors and Concurrent Pascal. It has no merit."

Still, with a bit of discipline, you can implement a monitor in Java. As long as nobody does "client-side locking" with synchronized (obj) { ... } And sure, if a method does synchronized (this) for a shorter time than the whole method, that's cool too as an optimization.

But that has not been a mainstream thing for a long time. How many synchronized methods do you find in j.u.c.ConcurrentHashMap?	

Now, admittedly, there are several instances of synchronized (someSeeminglyRandomObject) in the implementation. Also, check out the use of lock objects in Writer/PrintWriter. It's complicated.

Nothing wrong with an expert using synchronized because it performs better. But that begs the question. Why does it perform better? Objects typed as locks are surely more suitable as locks than any old object. Their performance should be on par with intrinsic locks.

Cheers,

Cay

On 03/06/2024 15.26, robert engels wrote:
> They are one and the same when they lock on the object itself. Synchronized block statements allow the lock duration to be minimized while maintaining the natural code structure (I.e not adding additional methods).
> 
>> On Jun 3, 2024, at 8:24 AM, Cay Horstmann <cay at horstmann.com> wrote:
>>
>> I am not talking about synchronized methods but about block statements (JLS 14.19).
>>
>> synchronized (obj) {
>>
>> }
>>
>>> On 03/06/2024 14.31, robert engels wrote:
>>> Reference for synchronized being a code smell?
>>> Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc.
>>>>> On Jun 3, 2024, at 2:21 AM, Cay Horstmann <cay.horstmann at gmail.com> wrote:
>>>>
>>>> On 02/06/2024 13.07, Andrew Haley wrote:
>>>>>> On 6/1/24 17:56, Alex wrote:
>>>>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods?
>>>>> I'd use Lock for the future. Synchronized plays very badly with Value
>>>>> Objects, for example. Being able to synchronize on any object is something
>>>>> of a legacy feature.
>>>>
>>>> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.)
>>>>
>>>> --
>>>>
>>>> Cay S. Horstmann | https://horstmann.com
>>
>> --
>>
>> --
>>
>> Cay S. Horstmann | https://horstmann.com

-- 

--

Cay S. Horstmann | https://horstmann.com