thread conditional code

Robin Becker robin at jessikat.fsnet.co.uk
Sat Apr 14 08:57:31 EDT 2001


In article <mailman.987247039.25991.python-list at python.org>, Tim Peters
<tim.one at home.com> writes
...
>> That way I could conditionally lock access to contentious
>> variables and avoid thread overhead when not needed.
>
>I'm afraid the only way to be sure of that is to build Python without
>threads -- only the OS knows how many threads exist at any given time.  If
>it's *possible* for another thread to pop into existence in your Python code,
>then you have to lock even before it pops into existence, lest it pop into
>existence "in the middle" of one of your critical sections that you cleverly
>avoided locking, and then enter the (unlocked) critical section at the same
>time.  If the threads you deal with are too well behaved for that, then
>there's no need for any locks at all <wink>.
>
>trying-to-cheat-locks-is-the-#1-cause-of-thread-disasters-ly y'rs  - tim
>
>
if only one (the main) thread exists at the beginning of my critical
section and I'm not creating any threads how could one pop into
existence?

If python threads aren't initialised and I don't do the initialisation
who else can do it? What I'm really asking is how to avoid initialising
the threading checks without losing the possibility of locking.

I assumed probably wrongly that there is an overhead to running multiple
threads because of the ceval thread switch tests; after scanning the
source code I suspect you have the thread switch overhead whether or not
the thread stuff is initialized and then it makes no sense to avoid
using it.
-- 
Robin Becker



More information about the Python-list mailing list