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!

Can you step through it with a C/C++ debugger to see where it goes wrong?

Yes.  Here's what I think the problem is:  InterlockedCompareExchange 
called from EnterNonRecursiveMutex in thread_nt.h:101 seems to returns 
(-1) as 0x00000000FFFFFFFF instead of 0xFFFFFFFFFFFFFFFF.  Still working 
out why though...

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.

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).

> 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?

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.

The patch doesn't apply (r58677 of release25-maint). Can you please
create an unified diff against the latest subversion checkout with svn
diff or TortoiseSVN?

$ patch -p1 < thread_nt_fix.patch
missing header for context diff at line 3 of patch
patching file Python/thread_nt.h
Hunk #2 FAILED at 14.
Hunk #3 FAILED at 40.
2 out of 3 hunks FAILED -- saving rejects to file Python/thread_nt.h.rej

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?

> 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?

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.

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/issue?@columns=title,id,activity,status&@sort=activity&@group=priority&@filter=versions,status&@pagesize=50&@startwith=0&status=1&versions=2

I guess at least the urgent and high priority bugs have to be addressed
for the new release.

Christian

The problem was fixed and the OP suggested to close the bug.