> But is it such a good idea to do? What if critical section is at two or
> more different places at once? How will you deal with
>
> def increment(self):
> try self.counter_lock:
> self.counter += 1
def increment(self):
synchronize self.counter:
self.counter += 1
>
> def decrement(self):
> try self.counter_lock:
> self.counter -= 1
def decrement(self):
synchronize self.counter:
self.counter -= 1
> (Suppose, it's not simple or elegant to do it in one place:
>
> def change(self, delta=1):
> try self.counter_lock:
> self.counter += delta
def change(self, delta=1):
synchronize self.counter:
self.counter += data
No explicit lock is necessary. Any object may be synchronized upon
(except, perhaps, None). The first time an object is synchronized, a lock
is invisibly associated with it behind the scenes, you cannot (and should
not) access this lock. The lock exists for the life of the object it
synchronizes. When a synchronize block is entered, the lock is acquire()d
and and release()d when the block is exited.
Very similar to the way Java does it:
http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#255769
except that in addition I propose an 'asynchronize' keyword that is used
inside a synchronized block to temporarily unlock it to do, for example,
blocking IO, or any other blocking operation that does not require
synchronization.
-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