From 1fff05c7c1c3e6a4cf48f0f0ec0b56381e4454a7 Mon Sep 17 00:00:00 2001 From: David Goodger Date: Sat, 14 Jun 2003 22:40:36 +0000 Subject: [PATCH] new PEP --- pep-0000.txt | 2 + pep-0319.txt | 497 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 499 insertions(+) create mode 100644 pep-0319.txt diff --git a/pep-0000.txt b/pep-0000.txt index e27ae35f9..92ab1045e 100644 --- a/pep-0000.txt +++ b/pep-0000.txt @@ -118,6 +118,7 @@ Index by Category S 315 Enhanced While Loop Carroll S 317 Eliminate Implicit Exception Instantiation Taschuk S 318 Function/Method Decorator Syntax Smith + S 319 Python Synchronize/Asynchronize Block Pelletier S 754 IEEE 754 Floating Point Special Values Warnes Finished PEPs (done, implemented in CVS) @@ -329,6 +330,7 @@ Numerical Index SD 316 Programming by Contract for Python Way S 317 Eliminate Implicit Exception Instantiation Taschuk S 318 Function/Method Decorator Syntax Smith + S 319 Python Synchronize/Asynchronize Block Pelletier SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes diff --git a/pep-0319.txt b/pep-0319.txt new file mode 100644 index 000000000..abdc74b90 --- /dev/null +++ b/pep-0319.txt @@ -0,0 +1,497 @@ +PEP: 319 +Title: Python Synchronize/Asynchronize Block +Version: $Revision$ +Last-Modified: $Date$ +Author: Michel Pelletier +Status: Draft +Type: Standards Track +Created: 24-Feb-2003 +Python-Version: 2.4? +Post-History: + + +Abstract + + This PEP proposes adding two new keywords to Python, `synchronize' + and 'asynchronize'. + + +The `synchronize' Keyword + + The concept of code synchronization in Python is too low-level. + To synchronize code a programmer must be aware of the details of + the following pseudo-code pattern: + + initialize_lock() + + ... + + acquire_lock() + try: + change_shared_data() + finally: + release_lock() + + This synchronized block pattern is not the only pattern (more + discussed below) but it is very common. This PEP proposes + replacing the above code with the following equivalent: + + synchronize: + change_shared_data() + + The advantages of this scheme are simpler syntax and less room for + user error. Currently users are required to write code about + acquiring and releasing thread locks in 'try/finally' blocks; + errors in this code can cause notoriously difficult concurrent + thread locking issues. + + +The `asynchronize' Keyword + + While executing a `synchronize' block of code a programmer may + want to "drop back" to running asynchronously momentarily to run + blocking input/output routines or something else that might take a + indeterminate amount of time and does not require synchronization. + This code usually follows the pattern: + + initialize_lock() + + ... + + acquire_lock() + try: + change_shared_data() + release_lock() # become async + do_blocking_io() + acquire_lock() # sync again + change_shared_data2() + + finally: + release_lock() + + The asynchronous section of the code is not very obvious visually, + so it is marked up with comments. Using the proposed + 'asynchronize' keyword this code becomes much cleaner, easier to + understand, and less prone to error: + + synchronize: + change_shared_data() + + asynchronize: + do_blocking_io() + + change_shared_data2() + + Encountering an `asynchronize' keyword inside a non-synchronized + block can raise either an error or issue a warning (as all code + blocks are implicitly asynchronous anyway). It is important to + note that the above example is *not* the same as: + + synchronize: + change_shared_data() + + do_blocking_io() + + synchronize: + change_shared_data2() + + Because both synchronized blocks of code may be running inside the + same iteration of a loop, Consider: + + while in_main_loop(): + synchronize: + change_shared_data() + + asynchronize: + do_blocking_io() + + change_shared_data2() + + Many threads may be looping through this code. Without the + 'asynchronize' keyword one thread cannot stay in the loop and + release the lock at the same time while blocking IO is going on. + This pattern of releasing locks inside a main loop to do blocking + IO is used extensively inside the CPython interpreter itself. + + +Synchronization Targets + + As proposed the `synchronize' and `asynchronize' keywords + synchronize a block of code. However programmers may want to + specify a target object that threads synchronize on. Any object + can be a synchronization target. + + Consider a two-way queue object: two different objects are used by + the same `synchronize' code block to synchronize both queues + separately in the 'get' method: + + class TwoWayQueue: + def __init__(self): + self.front = [] + self.rear = [] + + def putFront(self, item): + self.put(item, self.front) + + def getFront(self): + item = self.get(self.front) + return item + + def putRear(self, item): + self.put(item, self.rear) + + def getRear(self): + item = self.get(self.rear) + return item + + def put(self, item, queue): + synchronize queue: + queue.append(item) + + def get(self, queue): + synchronize queue: + item = queue[0] + del queue[0] + return item + + Here is the equivalent code in Python as it is now without a + `synchronize' keyword: + + import thread + + class LockableQueue: + + def __init__(self): + self.queue = [] + self.lock = thread.allocate_lock() + + class TwoWayQueue: + def __init__(self): + self.front = LockableQueue() + self.rear = LockableQueue() + + def putFront(self, item): + self.put(item, self.front) + + def getFront(self): + item = self.get(self.front) + return item + + def putRear(self, item): + self.put(item, self.rear) + + def getRear(self): + item = self.get(self.rear) + return item + + def put(self, item, queue): + queue.lock.acquire() + try: + queue.append(item) + finally: + queue.lock.release() + + def get(self, queue): + queue.lock.acquire() + try: + item = queue[0] + del queue[0] + return item + finally: + queue.lock.release() + + The last example had to define an extra class to associate a lock + with the queue where the first example the `synchronize' keyword + does this association internally and transparently. + + +Other Patterns that Synchronize + + There are some situations where the `synchronize' and + `asynchronize' keywords cannot entirely replace the use of lock + methods like `acquire' and `release'. Some examples are if the + programmer wants to provide arguments for `acquire' or if a lock + is acquired in one code block but released in another, as shown + below. + + Here is a class from Zope modified to use both the `synchronize' + and `asynchronize' keywords and also uses a pool of explicit locks + that are acquired and released in different code blocks and thus + don't use `synchronize': + + import thread + from ZServerPublisher import ZServerPublisher + + class ZRendevous: + + def __init__(self, n=1): + pool=[] + self._lists=pool, [], [] + + synchronize: + while n > 0: + l=thread.allocate_lock() + l.acquire() + pool.append(l) + thread.start_new_thread(ZServerPublisher, + (self.accept,)) + n=n-1 + + def accept(self): + synchronize: + pool, requests, ready = self._lists + while not requests: + l=pool[-1] + del pool[-1] + ready.append(l) + + asynchronize: + l.acquire() + + pool.append(l) + + r=requests[0] + del requests[0] + return r + + def handle(self, name, request, response): + synchronize: + pool, requests, ready = self._lists + requests.append((name, request, response)) + if ready: + l=ready[-1] + del ready[-1] + l.release() + + Here is the original class as found in the + 'Zope/ZServer/PubCore/ZRendevous.py' module. The "convenience" of + the '_a' and '_r' shortcut names obscure the code: + + import thread + from ZServerPublisher import ZServerPublisher + + class ZRendevous: + + def __init__(self, n=1): + sync=thread.allocate_lock() + self._a=sync.acquire + self._r=sync.release + pool=[] + self._lists=pool, [], [] + self._a() + try: + while n > 0: + l=thread.allocate_lock() + l.acquire() + pool.append(l) + thread.start_new_thread(ZServerPublisher, + (self.accept,)) + n=n-1 + finally: self._r() + + def accept(self): + self._a() + try: + pool, requests, ready = self._lists + while not requests: + l=pool[-1] + del pool[-1] + ready.append(l) + self._r() + l.acquire() + self._a() + pool.append(l) + + r=requests[0] + del requests[0] + return r + finally: self._r() + + def handle(self, name, request, response): + self._a() + try: + pool, requests, ready = self._lists + requests.append((name, request, response)) + if ready: + l=ready[-1] + del ready[-1] + l.release() + finally: self._r() + + In particular the asynchronize section of the `accept' method is + not very obvious. To beginner programmers, `synchronize' and + `asynchronize' remove many of the problems encountered when + juggling multiple `acquire' and `release' methods on different + locks in different `try/finally' blocks. + + +Formal Syntax + + Python syntax is defined in a modified BNF grammar notation + described in the Python Language Reference [1]. This section + describes the proposed synchronization syntax using this grammar: + + synchronize_stmt: 'synchronize' [test] ':' suite + asynchronize_stmt: 'asynchronize' [test] ':' suite + compound_stmt: ... | synchronized_stmt | asynchronize_stmt + + (The '...' indicates other compound statements elided). + + +Proposed Implementation + + The author of this PEP has not explored an implementation yet. + There are several implementation issues that must be resolved. + The main implementation issue is what exactly gets locked and + unlocked during a synchronized block. + + During an unqualified synchronized block (the use of the + `synchronize' keyword without an target argument) a lock could be + created and associated with the synchronized code block object. + Any threads that are to execute the block must first acquire the + code block lock. + + When an `asynchronize' keyword is encountered in a `synchronize' + block the code block lock is unlocked before the inner block is + executed and re-locked when the inner block terminates. + + When a synchronized block target is specified the object is + associated with a lock. How this is implemented cleanly is + probably the highest risk of this proposal. Java Virtual Machines + typically associate a special hidden lock object with target + object and use it to synchronized the block around the target + only. + + +Backward Compatibility + + Backward compatibility is solved with the new `from __future__' + Python syntax [2], and the new warning framework [3] to evolve the + Python language into phasing out any conflicting names that use + the new keywords `synchronize' and `asynchronize'. To use the + syntax now, a developer could use the statement: + + from __future__ import threadsync # or whatever + + In addition, any code that uses the keyword `synchronize' or + `asynchronize' as an identifier will be issued a warning from + Python. After the appropriate period of time, the syntax would + become standard, the above import statement would do nothing, and + any identifiers named `synchronize' or `asynchronize' would raise + an exception. + + +PEP 310 Reliable Acquisition/Release Pairs + + PEP 310 [4] proposes the 'with' keyword that can serve the same + function as 'synchronize' (but no facility for 'asynchronize'). + The pattern: + + initialize_lock() + + with the_lock: + change_shared_data() + + is equivalent to the proposed: + + synchronize the_lock: + change_shared_data() + + PEP 310 must synchronize on an exsiting lock, while this PEP + proposes that unqualified 'synchronize' statements synchronize on + a global, internal, transparent lock in addition to qualifiled + 'synchronize' statements. The 'with' statement also requires lock + initialization, while the 'synchronize' statment can synchronize + on any target object *including* locks. + + While limited in this fashion, the 'with' statment is more + abstract and serves more purposes than synchronization. For + example, transactions could be used with the 'with' keyword: + + initialize_transaction() + + with my_transaction: + do_in_transaction() + + # when the block terminates, the transaction is commited. + + The 'synchronize' and 'asynchronize' keywords cannot serve this or + any other general acquire/release pattern other than thread + synchronization. + + +How Java Does It + + Java defines a 'synchronized' keyword (note the grammatical tense + different between the Java keyword and this PEP's 'synchronize') + which must be qualified on any object. The syntax is: + + synchronized (Expression) Block + + Expression must yeild a valid object (null raises an error and + exceptions during 'Expression' terminate the 'synchronized' block + for the same reason) upon which 'Block' is synchronized. + + +How Jython Does It + + Jython uses a 'synchronize' class with the static method + 'make_synchronized' that accepts one callable argument and returns + a newly created, synchronized, callable "wrapper" around the + argument. + + +Summary of Proposed Changes to Python + + Adding new `synchronize' and `asynchronize' keywords to the + language. + + +Risks + + This PEP proposes adding two keywords to the Python language. This + may break code. + + There is no implementation to test. + + It's not the most important problem facing Python programmers + today (although it is a fairly notorious one). + + The equivalent Java keyword is the past participle 'synchronized'. + This PEP proposes the present tense, 'synchronize' as being more + in spirit with Python (there being less distinction between + compile-time and run-time in Python than Java). + + +Dissenting Opinion + + This PEP has not been discussed on python-dev. + + +References + + [1] The Python Language Reference + http://www.python.org/doc/current/ref/ref.html + + [2] PEP 236, Back to the __future__, Peters + http://python.sourceforge.net/peps/pep-0236.html + + [3] PEP 230, Warning Framework, van Rossum + http://python.sourceforge.net/peps/pep-0236.html + + [4] PEP 310, Reliable Acquisition/Release Pairs, Hudson, Moore + http://www.python.org/peps/pep-0310.html + + +Copyright + + This document has been placed in the public domain. + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +sentence-end-double-space: t +fill-column: 70 +End: