cpython/Python/thread_nt.h

316 lines
8.0 KiB
C
Raw Normal View History

1995-01-17 12:29:31 -04:00
/* This code implemented by Dag.Gruneau@elsa.preseco.comm.se */
/* Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru */
/* Eliminated some memory leaks, gsw@agere.com */
1995-01-17 12:29:31 -04:00
#include <windows.h>
#include <limits.h>
#include <process.h>
1995-01-17 12:29:31 -04:00
typedef struct NRMUTEX {
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) ;
mutex->hevent = NULL ; /* Just in case */
}
DWORD EnterNonRecursiveMutex(PNRMUTEX mutex, BOOL wait)
{
/* Assume that the thread waits successfully */
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) ?
/* Some thread owns the mutex, let's wait... */
WaitForSingleObject(mutex->hevent, INFINITE) : WAIT_OBJECT_0 ;
mutex->thread_id = GetCurrentThreadId() ; /* We own it */
return ret ;
}
BOOL LeaveNonRecursiveMutex(PNRMUTEX mutex)
{
/* We don't own the mutex */
mutex->thread_id = 0 ;
return
InterlockedDecrement(&mutex->owned) < 0 ||
SetEvent(mutex->hevent) ; /* Other threads are waiting, wake one on them up */
}
PNRMUTEX AllocNonRecursiveMutex(void)
{
PNRMUTEX mutex = (PNRMUTEX)malloc(sizeof(NRMUTEX)) ;
if (mutex && !InitializeNonRecursiveMutex(mutex))
{
free(mutex) ;
mutex = NULL ;
}
return mutex ;
}
void FreeNonRecursiveMutex(PNRMUTEX mutex)
{
if (mutex)
{
DeleteNonRecursiveMutex(mutex) ;
free(mutex) ;
}
}
long PyThread_get_thread_ident(void);
1995-01-17 12:29:31 -04:00
/*
* Initialization of the C package, should not be needed.
*/
static void PyThread__init_thread(void)
1995-01-17 12:29:31 -04:00
{
}
/*
* Thread support.
*/
typedef struct {
void (*func)(void*);
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
void *arg;
long id;
HANDLE done;
} callobj;
static int
bootstrap(void *call)
{
callobj *obj = (callobj*)call;
/* copy callobj since other thread might free it before we're done */
void (*func)(void*) = obj->func;
void *arg = obj->arg;
obj->id = PyThread_get_thread_ident();
ReleaseSemaphore(obj->done, 1, NULL);
func(arg);
return 0;
}
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
long
PyThread_start_new_thread(void (*func)(void *), void *arg)
1995-01-17 12:29:31 -04:00
{
2006-02-15 13:27:45 -04:00
uintptr_t rv;
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
callobj obj;
1995-01-17 12:29:31 -04:00
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
dprintf(("%ld: PyThread_start_new_thread called\n",
PyThread_get_thread_ident()));
1995-01-17 12:29:31 -04:00
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
obj.id = -1; /* guilty until proved innocent */
obj.func = func;
obj.arg = arg;
obj.done = CreateSemaphore(NULL, 0, 1, NULL);
if (obj.done == NULL)
return -1;
rv = _beginthread(bootstrap, 0, &obj); /* use default stack size */
2006-02-15 13:27:45 -04:00
if (rv == (uintptr_t)-1) {
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
/* I've seen errno == EAGAIN here, which means "there are
* too many threads".
*/
dprintf(("%ld: PyThread_start_new_thread failed: %p errno %d\n",
PyThread_get_thread_ident(), rv, errno));
obj.id = -1;
1995-01-17 12:29:31 -04:00
}
An Anonymous Coward on c.l.py posted a little program with bizarre behavior, creating many threads very quickly. A long debugging session revealed that the Windows implementation of PyThread_start_new_thread() was choked with "laziness" errors: 1. It checked MS _beginthread() for a failure return, but when that happened it returned heap trash as the function result, instead of an id of -1 (the proper error-return value). 2. It didn't consider that the Win32 CreateSemaphore() can fail. 3. When creating a great many threads very quickly, it's quite possible that any particular bootstrap call can take virtually any amount of time to return. But the code waited for a maximum of 5 seconds, and didn't check to see whether the semaphore it was waiting for got signaled. If it in fact timed out, the function could again return heap trash as the function result. This is actually what confused the test program, as the heap trash usually turned out to be 0, and then multiple threads all got id 0 simultaneously, confusing the hell out of threading.py's _active dict (mapping id to thread object). A variety of baffling behaviors followed from that. WRT #1 and #2, error returns are checked now, and "thread.error: can't start new thread" gets raised now if a new thread (or new semaphore) can't be created. WRT #3, we now wait for the semaphore without a timeout. Also removed useless local vrbls, folded long lines, and changed callobj to a stack auto (it was going thru malloc/free instead, for no discernible reason). Bugfix candidate.
2003-07-04 01:40:45 -03:00
else {
dprintf(("%ld: PyThread_start_new_thread succeeded: %p\n",
PyThread_get_thread_ident(), rv));
/* wait for thread to initialize, so we can get its id */
WaitForSingleObject(obj.done, INFINITE);
assert(obj.id != -1);
}
CloseHandle((HANDLE)obj.done);
return obj.id;
1995-01-17 12:29:31 -04:00
}
/*
* Return the thread Id instead of an handle. The Id is said to uniquely identify the
* thread in the system
*/
long PyThread_get_thread_ident(void)
1995-01-17 12:29:31 -04:00
{
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
return GetCurrentThreadId();
}
static void do_PyThread_exit_thread(int no_cleanup)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_exit_thread called\n", PyThread_get_thread_ident()));
1995-01-17 12:29:31 -04:00
if (!initialized)
if (no_cleanup)
_exit(0);
else
exit(0);
_endthread();
1995-01-17 12:29:31 -04:00
}
void PyThread_exit_thread(void)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_thread(0);
1995-01-17 12:29:31 -04:00
}
void PyThread__exit_thread(void)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_thread(1);
1995-01-17 12:29:31 -04:00
}
#ifndef NO_EXIT_PROG
static void do_PyThread_exit_prog(int status, int no_cleanup)
1995-01-17 12:29:31 -04:00
{
dprintf(("PyThread_exit_prog(%d) called\n", status));
1995-01-17 12:29:31 -04:00
if (!initialized)
if (no_cleanup)
_exit(status);
else
exit(status);
}
void PyThread_exit_prog(int status)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_prog(status, 0);
1995-01-17 12:29:31 -04:00
}
void PyThread__exit_prog(int status)
1995-01-17 12:29:31 -04:00
{
do_PyThread_exit_prog(status, 1);
1995-01-17 12:29:31 -04:00
}
#endif /* NO_EXIT_PROG */
/*
* Lock support. It has too be implemented as semaphores.
* I [Dag] tried to implement it with mutex but I could find a way to
* tell whether a thread already own the lock or not.
*/
PyThread_type_lock PyThread_allocate_lock(void)
1995-01-17 12:29:31 -04:00
{
PNRMUTEX aLock;
1995-01-17 12:29:31 -04:00
dprintf(("PyThread_allocate_lock called\n"));
1995-01-17 12:29:31 -04:00
if (!initialized)
PyThread_init_thread();
1995-01-17 12:29:31 -04:00
aLock = AllocNonRecursiveMutex() ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_allocate_lock() -> %p\n", PyThread_get_thread_ident(), aLock));
1995-01-17 12:29:31 -04:00
return (PyThread_type_lock) aLock;
1995-01-17 12:29:31 -04:00
}
void PyThread_free_lock(PyThread_type_lock aLock)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_free_lock(%p) called\n", PyThread_get_thread_ident(),aLock));
1995-01-17 12:29:31 -04:00
FreeNonRecursiveMutex(aLock) ;
1995-01-17 12:29:31 -04:00
}
/*
* Return 1 on success if the lock was acquired
*
* and 0 if the lock was not acquired. This means a 0 is returned
* if the lock has already been acquired by this thread!
*/
int PyThread_acquire_lock(PyThread_type_lock aLock, int waitflag)
1995-01-17 12:29:31 -04:00
{
int success ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_acquire_lock(%p, %d) called\n", PyThread_get_thread_ident(),aLock, waitflag));
1995-01-17 12:29:31 -04:00
success = aLock && EnterNonRecursiveMutex((PNRMUTEX) aLock, (waitflag ? INFINITE : 0)) == WAIT_OBJECT_0 ;
1995-01-17 12:29:31 -04:00
dprintf(("%ld: PyThread_acquire_lock(%p, %d) -> %d\n", PyThread_get_thread_ident(),aLock, waitflag, success));
1995-01-17 12:29:31 -04:00
return success;
}
void PyThread_release_lock(PyThread_type_lock aLock)
1995-01-17 12:29:31 -04:00
{
dprintf(("%ld: PyThread_release_lock(%p) called\n", PyThread_get_thread_ident(),aLock));
1995-01-17 12:29:31 -04:00
if (!(aLock && LeaveNonRecursiveMutex((PNRMUTEX) aLock)))
dprintf(("%ld: Could not PyThread_release_lock(%p) error: %l\n", PyThread_get_thread_ident(), aLock, GetLastError()));
1995-01-17 12:29:31 -04:00
}