Michel Pelletier writes: [...] > No explicit lock is necessary. Any object may be synchronized upon > (except, perhaps, None). [...] In my opinion, this is one of the glaring *flaws* of the java threading and synchronization model. Locks are entities of their own, to be used when synchronization is needed. There does NOT need to be a lock associated with each and every object in the system (even if, as an implementation detail, that lock isn't created unless it is used). If a programmer needs to synchronize, they should THINK about what exactly needs to be synchronized with what, and create an appropriately named lock. Explicit is better than implicit. Making it "easy" for programmers who use threads by making unnecessary for them to think about details like which lock is used for what synchronization, is almost certainly NOT doing them a favor... instead, it's just inviting subtle, hard-to- find bugs. -- Michael Chermside
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4