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/036457.html below:

[Python-Dev] New PEP: 319

[Python-Dev] New PEP: 319Jack Jansen Jack.Jansen@cwi.nl
Tue, 17 Jun 2003 22:04:04 +0200
On dinsdag, jun 17, 2003, at 21:36 Europe/Amsterdam, Michel Pelletier 
wrote:

> Maybe I did this wrong, but aren't the two (and Greg's "synchronized 
> class")
> all susceptible to this problem and it's not specificly a failure of 
> the
> 'synchronize' keyword?

Yes, all mechanisms are susceptible to the same problem, they're 
probably all three functionally equivalent (i.e. anything you can code 
with one you can code with the other).

The point I'm trying to make is that designing your locks is hard work 
especially if there are many locks. Let's for the sake of argument say 
that the amount of work to get things right is quadratic in the number 
of locks. This means that any language construct that invites people to 
create many locks will make it more difficult to get the code right.

I realise the argument I make sound pedantic (let's not make it too 
easy to do locking, so that only people who know what they're doing 
will use locking), but that's the way I actually do feel about the 
subject.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -




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