Kiuhnm wrote:
> I'm about to write my first module and I don't know how I should handle
> multithreading/-processing.
> I'm not doing multi-threading inside my module. I'm just trying to make
> it thread-safe so that users *can* do multi-threading.
There are a couple conventions to follow. Trying to anticipate the
threading needs of users and then locking everything for the worst
case is a bad idea.
So what are the conventions? Unless documented otherwise, classes
don't guarantee that each instance can be used by more then one
thread. Most of the classes in Python's standard library are not one-
instance-multiple-threads safe. An important documented exception is
queue.queue.
Classes should be safe for instance-per-thread multi-threading, unless
documented otherwise. Likewise, functions should be thread safe under
the assumption that their arguments are not shared between threads,
which brings us to your example:
> For instance, let's say I want to make this code thread-safe:
>
> --->
> myDict = {}
>
> def f(name, val):
> if name not in myDict:
> myDict[name] = val
> return myDict[name]
> <---
First, don't re-code Python's built-ins. The example is a job for
dict.setdefault(). Language built-ins are already thread-safe (at
least in CPython), though not meant as thread synchronization
primitives.
Second, the example suggests no obvious reason for the single global
variabel. It could be a class for which users can make any number of
instances.
Third, there are cases where you want a single global. Most of the
time I'd recommend warning users about threading assumptions.
-Bryan
--
http://mail.python.org/mailman/listinfo/python-list
