]> granicus.if.org Git - python/commit
Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru,
authorGuido van Rossum <guido@python.org>
Thu, 4 May 2000 18:47:15 +0000 (18:47 +0000)
committerGuido van Rossum <guido@python.org>
Thu, 4 May 2000 18:47:15 +0000 (18:47 +0000)
commit706262bde0e93cc14023a76da3b0836b62e51e4d
treedc58c7bcce57da2e208b0c7404bfeca61833a5cc
parent69529ad0ccbe2fb68427de92763d7a5322b63d31
Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru,
who wrote:

Here's the new version of thread_nt.h.  More particular, there is a
new version of thread lock that uses kernel object (e.g. semaphore)
only in case of contention; in other case it simply uses interlocked
functions, which are faster by the order of magnitude.  It doesn't
make much difference without threads present, but as soon as thread
machinery initialised and (mostly) the interpreter global lock is on,
difference becomes tremendous.  I've included a small script, which
initialises threads and launches pystone.  With original thread_nt.h,
Pystone results with initialised threads are twofold worse then w/o
threads.  With the new version, only 10% worse.  I have used this
patch for about 6 months (with threaded and non-threaded
applications).  It works remarkably well (though I'd desperately
prefer Python was free-threaded; I hope, it will soon).
Python/thread_nt.h