diff options
author | Guido van Rossum <guido@python.org> | 2000-05-04 18:47:15 (GMT) |
---|---|---|
committer | Guido van Rossum <guido@python.org> | 2000-05-04 18:47:15 (GMT) |
commit | 706262bde0e93cc14023a76da3b0836b62e51e4d (patch) | |
tree | dc58c7bcce57da2e208b0c7404bfeca61833a5cc /Lib | |
parent | 69529ad0ccbe2fb68427de92763d7a5322b63d31 (diff) | |
download | cpython-706262bde0e93cc14023a76da3b0836b62e51e4d.zip cpython-706262bde0e93cc14023a76da3b0836b62e51e4d.tar.gz cpython-706262bde0e93cc14023a76da3b0836b62e51e4d.tar.bz2 |
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).
Diffstat (limited to 'Lib')
0 files changed, 0 insertions, 0 deletions