another thread on Python threading

The pitfall here is that to reduce code duplication,
you might initialize certain variables in a method
called by __init__, because your object might want to
return to its initial state.

I've recently been working on an application[1] which does quite a bit
of searching through large data structures and string matching, and I
was thinking that it would help to put some of this CPU-intensive work
in another thread, but of course this won't work because of Python's
GIL.

There's a lot of past discussion on this, and I want to bring it up
again because with the work on Python 3000, I think it is worth trying
to take a look at what can be done to address portions of the problem
through language changes.

I remember reading (though I can't find it now) one person's attempt
at true multithreaded programming involved adding a mutex to all
object access. The obvious question though is - why don't other true
multithreaded languages like Java need to lock an object when making
changes?

== Why hasn't __slots__ been successful? ==

I very rarely see Python code use __slots__. I think there are
several reasons for this. The first is that a lot of programs don't
need to optimize on this level. The second is that it's annoying to
use, because it means you have to type your member variables *another*
time (in addition to __init__ for example), which feels very un-
Pythonic.

== Defining object attributes ==

In my Python code, one restriction I try to follow is to set all the
attributes I use for an object in __init__. You could do this as
class member variables, but often I want to set them in __init__
anyways from constructor arguments, so "defining" them in __init__
means I only type them once, not twice.

One random idea is to for Python 3000, make the equivalent of
__slots__ the default, *but* instead gather
the set of attributes from all member variables set in __init__. For
example, if I write:

class Foo(object):
def __init__(self, bar=None):
self.__baz = 20
if bar:
self.__bar = bar
else:
self.__bar = time.time()

f = Foo()
f.otherattr = 40 # this would be an error! Can't add random
attributes not defined in __init__

I would argue that the current Python default of supporting adding
random attributes is almost never what you really want. If you *do*
want to set random attributes, you almost certainly want to be using a
dictionary or a subclass of one, not an object. What's nice about the
current Python is that you don't need to redundantly type things, and
we should preserve that while still allowing more efficient
implementation strategies.

= Limited threading =

Now, I realize there are a ton of other things the GIL protects other
than object dictionaries; with true threading you would have to touch
the importer, the garbage collector, verify all the C extension
modules, etc. Obviously non-trivial. What if as an initial push
towards real threading, Python had support for "restricted threads".
Essentially, restricted threads would be limited to a subset of the
standard library that had been verified for thread safety, would not
be able to import new modules, etc.

Something like this:

def datasearcher(li st, queue):
for item in list:
if item.startswith ('foo'):
queue.put(item)
queue.done()

vals = ['foo', 'bar']
queue = queue.Queue()
threading.start _restricted_thr ead(datasearche r, vals, queue)
def print_item(item ):
print item
queue.set_callb ack(print_item)

Making up some API above I know, but the point here is "datasearch er"
could pretty easily run in a true thread and touch very little of the
interpreter; only support for atomic reference counting and a
concurrent garbage collector would be needed.

Thoughts?

[1] http://submind.verbum.org/hotwire/wiki

cgwalt...@gmail .com wrote:

I've recently been working on an application[1] which does quite a bit
of searching through large data structures and string matching, and I
was thinking that it would help to put some of this CPU-intensive work
in another thread, but of course this won't work because of Python's
GIL.

If you are doing string searching, implement the algorithm in C, and
call out to the C (remembering to release the GIL).

There's a lot of past discussion on this, and I want to bring it up
again because with the work on Python 3000, I think it is worth trying
to take a look at what can be done to address portions of the problem
through language changes.

Not going to happen. All Python 3000 PEPs had a due-date at least a
month ago (possibly even 2), so you are too late to get *any*
substantial change in.

I remember reading (though I can't find it now) one person's attempt
at true multithreaded programming involved adding a mutex to all
object access. The obvious question though is - why don't other true
multithreaded languages like Java need to lock an object when making
changes?

From what I understand, the Java runtime uses fine-grained locking on
all objects. You just don't notice it because you don't need to write
the acquire()/release() calls. It is done for you. (in a similar
fashion to Python's GIL acquisition/release when switching threads)

They also have a nice little decorator-like thingy (I'm not a Java guy,
so I don't know the name exactly) called 'synchronize', which locks and
unlocks the object when accessing it through a method.

>
- Josiah

== Why hasn't __slots__ been successful? ==

I very rarely see Python code use __slots__. I think there are
several reasons for this. The first is that a lot of programs don't
need to optimize on this level. The second is that it's annoying to
use, because it means you have to type your member variables *another*
time (in addition to __init__ for example), which feels very un-
Pythonic.

== Defining object attributes ==

In my Python code, one restriction I try to follow is to set all the
attributes I use for an object in __init__. You could do this as
class member variables, but often I want to set them in __init__
anyways from constructor arguments, so "defining" them in __init__
means I only type them once, not twice.

One random idea is to for Python 3000, make the equivalent of
__slots__ the default, *but* instead gather
the set of attributes from all member variables set in __init__. For
example, if I write:

class Foo(object):
def __init__(self, bar=None):
self.__baz = 20
if bar:
self.__bar = bar
else:
self.__bar = time.time()

f = Foo()
f.otherattr = 40 # this would be an error! Can't add random
attributes not defined in __init__

I would argue that the current Python default of supporting adding
random attributes is almost never what you really want. If you *do*
want to set random attributes, you almost certainly want to be using a
dictionary or a subclass of one, not an object. What's nice about the
current Python is that you don't need to redundantly type things, and
we should preserve that while still allowing more efficient
implementation strategies.

= Limited threading =

Now, I realize there are a ton of other things the GIL protects other
than object dictionaries; with true threading you would have to touch
the importer, the garbage collector, verify all the C extension
modules, etc. Obviously non-trivial. What if as an initial push
towards real threading, Python had support for "restricted threads".
Essentially, restricted threads would be limited to a subset of the
standard library that had been verified for thread safety, would not
be able to import new modules, etc.

Something like this:

def datasearcher(li st, queue):
for item in list:
if item.startswith ('foo'):
queue.put(item)
queue.done()

vals = ['foo', 'bar']
queue = queue.Queue()
threading.start _restricted_thr ead(datasearche r, vals, queue)
def print_item(item ):
print item
queue.set_callb ack(print_item)

Making up some API above I know, but the point here is "datasearch er"
could pretty easily run in a true thread and touch very little of the
interpreter; only support for atomic reference counting and a
concurrent garbage collector would be needed.

Thoughts?

[1]http://submind.verbum. org/hotwire/wiki

>
If you are doing string searching, implement the algorithm in C, and
call out to the C (remembering to release the GIL).

There's a lot of past discussion on this, and I want to bring it up
again because with the work on Python 3000, I think it is worth trying
to take a look at what can be done to address portions of the problem
through language changes.

Not going to happen. All Python 3000 PEPs had a due-date at least a
month ago (possibly even 2), so you are too late to get *any*
substantial change in.

On Jun 4, 3:10 am, Josiah Carlson <josiah.carl... @sbcglobal.net>
wrote:

> From what I understand, the Java runtime uses fine-grained locking on
all objects. You just don't notice it because you don't need to write
the acquire()/release() calls. It is done for you. (in a similar
fashion to Python's GIL acquisition/release when switching threads)

The problem is CPython's reference counting. Access to reference
counts must be synchronized.
Java, IronPython and Jython uses another scheme for the garbage
collector and do not need a GIL.

Changing CPython's garbage collection from reference counting to a
generational GC will be a major undertaking. There are also pros and
cons to using reference counts instead of 'modern' garbage collectors.
For example, unless there are cyclic references, one can always know
when an object is garbage collected. One also avoids periodic delays
when garbage are collected, and memory use can be more modest then a
lot of small temporary objects are being used.

There are a number of different options for exploiting multiple CPUs
from CPython, including:

def synchronized(fu n):
from threading import RLock
rl = RLock()
def decorator(*args ,**kwargs):
with rl:
retv = fun(*args,**kwa rgs)
return retv
return decorator

It is not possible to define a 'synchronized' block though, as Python
do not have Lisp macros :(

lock = threading.Lock( )

with lock:
#synchronized block!
pass

However, locking isn't just for refcounts, it's to make sure that thread
A isn't mangling your object while thread B is traversing it.

With
object locking (course via the GIL, or fine via object-specific locks),
you get the same guarantees, with the problem being that fine-grained
locking is about a bazillion times more difficult to verify the lack of
deadlocks than a GIL-based approach.

It was done a while ago. The results? On a single-processor machine,
Python code ran like 1/4-1/3 the speed of the original runtime. When
using 4+ processors, there were some gains in threaded code, but not
substantial at that point.

My current favorite is the processing package (available from the Python
cheeseshop).

On Jun 4, 10:11 pm, Josiah Carlson <josiah.carl... @sbcglobal.net>
wrote:

> lock = threading.Lock( )

with lock:
#synchronized block!
pass

True, except that the lock has to be shared among the threads. This
explicit initiation of an reentrant lock is avoided in a Java
synchronized block.

On Jun 4, 10:11 pm, Josiah Carlson <josiah.carl... @sbcglobal.net>
wrote:

>However, locking isn't just for refcounts, it's to make sure that thread
A isn't mangling your object while thread B is traversing it.

>With
object locking (course via the GIL, or fine via object-specific locks),
you get the same guarantees, with the problem being that fine-grained
locking is about a bazillion times more difficult to verify the lack of
deadlocks than a GIL-based approach.

I think this is just as much a question of what the runtime should
guarantee. One don't need a guarantee that two threads are not
mangling the same object simultaneously. Instead, the runtime could
leave it to the programmer to use explicit locks on the object or
synchronized blocks to guarantee this for himself.

>It was done a while ago. The results? On a single-processor machine,
Python code ran like 1/4-1/3 the speed of the original runtime. When
using 4+ processors, there were some gains in threaded code, but not
substantial at that point.

I am not surprised. Reference counts are quite efficient, contrary to
common belief. The problem with reference counts is cyclic references
involving objects that define a __del__ method. As these objects are
not eligible for cyclic garbage collection, this can produce resource
leaks.