On Tuesday 17 June 2003 04:01, Jack Jansen wrote:
> but there's one I'd like to elaborate a little on:
>
> Michel Pelletier said:
> > I belive the reverse, synchronize will reduce user error and
> > deadlocking code. with explicit locks programmers will forget,=20
> > or become confused,
> > with when and how to explicitly lock and unlock.
>
> The problem is if one piece of code has
> =09synchronise a:
> =09=09...
> =09=09synchronise b:
> =09=09=09...
> and somewhere else you have
> =09synchronise b:
> =09=09...
> =09=09synchronise a:
> =09=09=09...
As you pointed out, the programmer must be aware of this when synchronizi=
ng=20
with any mechanism. Would you prefer the manual say "don't do the above"=
or=20
"don't do the below":
lock1 =3D thread.allocate_lock()
lock2 =3D thread.allocate_lock()
lock1.acquire()
try:
lock2.acquire()
try:
...
finally:
lock2.release()
finally:
lock1.release()
# and somewhere else you have
lock2.acquire()
try:
lock1.acquire()
try:
...
finally:
lock1.release()
finally:
lock2.release()
Maybe I did this wrong, but aren't the two (and Greg's "synchronized clas=
s")=20
all susceptible to this problem and it's not specificly a failure of the=20
'synchronize' keyword?
Thanks for your comments Jack, I'm going to add this to the discussion se=
ction=20
of the PEP.=20
-Michel
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