[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Christian Heimes added the comment: The problem was fixed and the OP suggested to close the bug. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Christian Heimes added the comment: Warren DeLano wrote: So I guess that automatically puts me in the **highly- motivated/willing-to-help** camp, if there's anything useful I can actually do towards 2.5.2. You can check every bugs related to 2.5 with urgent, high or no priority and see if the bugs needs to be fixed for 2.5.2. http://bugs.python.org/[EMAIL PROTECTED],id,activity,status@sort=activity@group=priority@filter=versions,status@pagesize=50@startwith=0status=1versions=2 I guess at least the urgent and high priority bugs have to be addressed for the new release. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: Can you step through it with a C/C++ debugger to see where it goes wrong? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: Hmm. Well, for one thing, we're falling back on Python's interlocked_cmp_xchg instead of using Windows' InterlockedCompareExchange (or should it InterlockCompareExchange64?). Python's implementation is clearly assuming 64 bit counters, but the other native Windows Interlocked* functions may indeed be operating on 32 bit counters, hence the mismatch. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: Disabling Python's emulated InterlockedCompareExchange (for Win95 compatibility) cures the problem, so the underlying question is why the existence of InterlockedCompareExchange is not being autodetected on 64 bit systems -- and that is apparently because GetProcAddress (kernel,InterlockedCompareExchange) returns NULL -- which makes sense since InterlockedCompareExchange appears to be implemented using macros instead of being served up through kernel32.dll. So is Win95 still a supported platform? If not, then perhaps InterlockedCompareExchange emulation can simply be deleted. If so, then either some other approach needs to be adopted to activate emulation, or the emulated code needs to be fixed to behave like the native windows functions (which appear to only operate on the lowest 32 bits). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: Disabling Python's emulated InterlockedCompareExchange (for Win95 compatibility) cures the problem, so the underlying question is why the existence of InterlockedCompareExchange is not being autodetected on 64 bit systems -- and that is apparently because GetProcAddress (kernel,InterlockedCompareExchange) returns NULL -- which makes sense since InterlockedCompareExchange appears to be implemented using macros instead of being served up through kernel32.dll. So is Win95 still a supported platform? Heavens no! If not, then perhaps InterlockedCompareExchange emulation can simply be deleted. Patch please? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment:
Patch attached. Do note that this patch will break threading on Win95
in order to achieve 64-bit compatibility. Win98 and up should be
fine -- however, that assertion has not yet been confirmed.
Added file: http://bugs.python.org/file8621/thread_nt_fix.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1332
__*** thread_nt.h Fri Oct 26 21:03:09 2007
--- Python-2.5.1/Python/thread_nt.h Fri Oct 26 21:03:34 2007
***
*** 1,9
--- 1,10
/* This code implemented by [EMAIL PROTECTED] */
/* Fast NonRecursiveMutex support by Yakov Markovitch, [EMAIL PROTECTED] */
/* Eliminated some memory leaks, [EMAIL PROTECTED] */
+ /* Nixed InterlockedCompareExchange emulation (x86_64:1, Win95:0), [EMAIL
PROTECTED] */
#include windows.h
#include limits.h
#ifdef HAVE_PROCESS_H
#include process.h
***
*** 13,88
LONG owned ;
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX ;
- typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID *dest, PVOID exc, PVOID
comperand) ;
-
- /* Sorry mate, but we haven't got InterlockedCompareExchange in Win95! */
- static PVOID WINAPI
- interlocked_cmp_xchg(PVOID *dest, PVOID exc, PVOID comperand)
- {
- static LONG spinlock = 0 ;
- PVOID result ;
- DWORD dwSleep = 0;
-
- /* Acqire spinlock (yielding control to other threads if cant aquire
for the moment) */
- while(InterlockedExchange(spinlock, 1))
- {
- // Using Sleep(0) can cause a priority inversion.
- // Sleep(0) only yields the processor if there's
- // another thread of the same priority that's
- // ready to run. If a high-priority thread is
- // trying to acquire the lock, which is held by
- // a low-priority thread, then the low-priority
- // thread may never get scheduled and hence never
- // free the lock. NT attempts to avoid priority
- // inversions by temporarily boosting the priority
- // of low-priority runnable threads, but the problem
- // can still occur if there's a medium-priority
- // thread that's always runnable. If Sleep(1) is used,
- // then the thread unconditionally yields the CPU. We
- // only do this for the second and subsequent even
- // iterations, since a millisecond is a long time to wait
- // if the thread can be scheduled in again sooner
- // (~100,000 instructions).
- // Avoid priority inversion: 0, 1, 0, 1,...
- Sleep(dwSleep);
- dwSleep = !dwSleep;
- }
- result = *dest ;
- if (result == comperand)
- *dest = exc ;
- /* Release spinlock */
- spinlock = 0 ;
- return result ;
- } ;
-
- static interlocked_cmp_xchg_t *ixchg;
-
BOOL
InitializeNonRecursiveMutex(PNRMUTEX mutex)
{
- if (!ixchg)
- {
- /* Sorely, Win95 has no InterlockedCompareExchange API (Win98
has), so we have to use emulation */
- HANDLE kernel = GetModuleHandle(kernel32.dll) ;
- if (!kernel || (ixchg = (interlocked_cmp_xchg_t
*)GetProcAddress(kernel, InterlockedCompareExchange)) == NULL)
- ixchg = interlocked_cmp_xchg ;
- }
-
mutex-owned = -1 ; /* No threads have entered NonRecursiveMutex */
mutex-thread_id = 0 ;
mutex-hevent = CreateEvent(NULL, FALSE, FALSE, NULL) ;
return mutex-hevent != NULL ; /* TRUE if the mutex is created */
}
- #ifdef InterlockedCompareExchange
- #undef InterlockedCompareExchange
- #endif
- #define InterlockedCompareExchange(dest,exchange,comperand) (ixchg((dest),
(exchange), (comperand)))
-
VOID
DeleteNonRecursiveMutex(PNRMUTEX mutex)
{
/* No in-use check */
CloseHandle(mutex-hevent) ;
--- 14,32
***
*** 96,106
DWORD ret ;
/* InterlockedIncrement(mutex-owned) == 0 means that no thread
currently owns the mutex */
if (!wait)
{
! if (InterlockedCompareExchange((PVOID *)mutex-owned,
(PVOID)0, (PVOID)-1) != (PVOID)-1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(mutex-owned) ?
--- 40,50
DWORD ret ;
/* InterlockedIncrement(mutex-owned) == 0 means that no thread
currently owns the mutex */
if (!wait)
{
! if (InterlockedCompareExchange(mutex-owned, 0, -1) != -1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(mutex-owned) ?
___
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: No need -- turns out the problem was fixed on April 21st a mere three days after Python 2.5.1 was released. Please close this issue -- my rookie mistake not working with SVN source from the start! (gee, I should have known better...) Sorry for wasting your time and mine. However, considering the severity of this problem (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think about issuing a 2.5.2 maintenance release? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: However, considering the severity of this problem (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think about issuing a 2.5.2 maintenance release? Neal Norwitz and Anthony Baxter have been planning to release 2.5.2 for a while now; unfortunately both seem too busy to make much progress. Any volunteers? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: I wouldn't know how take the lead, but with customers breathing down my neck for x64 support, my own threading.Rlock-dependent software product cannot support x64 until an official Python release supports it. So I guess that automatically puts me in the **highly- motivated/willing-to-help** camp, if there's anything useful I can actually do towards 2.5.2. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Changes by Warren DeLano: -- components: Windows nosy: delwarl severity: normal status: open title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
New submission from Warren DeLano: import threading rlock = threading.RLock() rlock.acquire(0) # always returns False with python-2.5.1.amd64.msi # even though rlock.acquire() # returns True as expected. # All attempts to acquire locks without blocking are foiled! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
