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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4