A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-June/036444.html below:

[Python-Dev] New PEP: 319

[Python-Dev] New PEP: 319Moore, Paul Paul.Moore@atosorigin.com
Tue, 17 Jun 2003 10:24:58 +0100
From: Michael Chermside [mailto:mcherm@mcherm.com]
> 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.

I agree entirely. Thank you for putting it so well.

Paul.



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