Hi Nicholas, On Thu, Sep 15, 2005 at 11:18:15AM -0500, Nicholas Riley wrote: > > non-GIL implementation of Python. > > This is what I'm working on (though from an academic context :), and > I've been in somewhat of a holding pattern recently - doing some small > experiments with CPython, reading and following mailing lists/IRC, > trying to figure out when PyPy is finished enough that I can start > doing work. > > Of course, if there's something I can do to help PyPy get to this > point, I'll help. Has anyone written anything about the (at least > near-term) plans for PyPy in the area of concurrency/locking?
Interesting. We should be about to consider alternate locking strategies right now. The current status is: we use GIL locking, and didn't even finish that -- the GIL is not released around system calls. Considering other locking strategies, I think the following one is possible. It would incur a small general run-time overhead, but it's of course all PyPy is about (whatever opinions might be heard around here :-) : avoiding as much as possible hard-wired design decisions and leaving compromizes to the choice of the user (or at least, for now, the person who translates and compiles PyPy). The naive locking idea is to put a cheap lock on each object, and then each space operation would first acquire the lock on its arguments and release it when it finishes. Recursive calls to the interpreter (i.e. calls to space operations that call back app-level Python code) would also release all the locks held by that thread. The locks should be re-entrants, i.e. not block if already held by the same thread. These locks can probably be optimized using some assumptions about our use case: we could for example acquire more locks when entering a space operation, but delay all releasing to the end of the bytecode (or even to the end of the next 'checkinterval' bytecodes), at which point we would bulk-release all locks held by the current thread. The above scheme is rather easy to implement as a proxy object space, doing the locking and then calling the standard object space. Other ideas are possible too; I'd be interested to hear about yours, what you've been playing with? A bientot, Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
