Synchronized methods and virtual threads

[Andrew Haley]

On 6/3/24 13:31, robert engels wrote:
 > Reference for synchronized being a code smell?

I'm not sure about any reference, but locking on arbitrary
objects makes it hard to reason about a program. At least Locks
are explicit locks, as advertised in their type.

 > Synchronized methods can be much more efficient than locks as
 > the runtime can optimize them away,

"Much more" is a bit of a stretch here, but admittedly they do
have better throughput in the mostly-uncontended case.

But re locks, I'm going to quote Nir Shavit:

"The main tools for handling concurrency in today's programming
languages are locks, software constructs that allow sequences of
loads and stores to access data in a mutually exclusive manner.
Indeed, lock-based programs have been known to deliver amazing
performance on multicore architectures. However, it is becoming
clear that, while using locks will allow us to continue to reduce
the time it takes programs to run, they will cause the time it
takes us to write and maintain our programs to shoot back up.

"The heart of the problem is, perhaps, that no one really knows
how to organize and maintain large systems that rely on locking.
Locks are not modular and do not compose, and the association
between locks and data is established mostly by convention.
Ultimately, the association exists only in the mind of the
programmer, and may be documented only in comments."

 > bias locking, etc.

It can't use biased locking any more.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671