semaphores and Rlocks

[Martin v. Löwis]

Jive Dadson <sdfadfsa at sdfasdfasdfa.invalid> writes:

> > > > > But I also found thread.c in the C sources, which appears to
> > > > > define semaphores and locks by means of the MS Windows API.
[...]
> I erred.  It is in thread_nt.h (dot h???) line 89, for example.

So you are probably seeing what I see: It does not define semaphores
and locks by means of the MS Windows API for semaphores and locks, but
by means of the Interlocked* API.

> > I fear that a portable solution is unimplementable. Strictly, using
> > threads is already non-portable, since some platforms may not support
> > threads at all. Even on those who do, adding timeouts may not be
> > possible.
>
> Portable to me means portable to at least Win32 and Unix/Linux/POSIX
> machines, using no C extension modules other than ones that come
> with the official Python distribution.

Ok, then no portable solution is possible, since the exposed API does
not support timeouts.

However, it is worse: If you were willing to define portable as "at
least Win32 and Unix/Linux/POSIX machines, including changes to C
extension modules that come with Python", it still would not be
implementable. Blocking on a lock is implemented with sem_wait(3) on
Unix/Linux/POSIX, and that does not support timeouts.

> The interface is simple and clean.  I have no problem with that.
> Perhaps I don't understand the code.  I have not studied it
> carefully.  But it looks to me as though the implementation puts the
> thread to sleep for periods of time during which a notify would be
> defered.

That impression is correct.

> I can't figure out the antecedants of all the pronouns in the
> preceeding block.  And I'm not sure exactly what you mean by
> "provide primatives".  I probably understand the software
> engineering principles involved.

I'm trying to say this: If you add a Semaphore function to
thread_nt.h, and the object returned from calling Semaphore supports
acquire and release, then this can replace the Semaphore function in
threading.py transparently, with no changes on other systems.

If you, however, add a CriticalRegion object to thread_nt.h, then you
need to provide the same object on all other systems as well.

> Do you know off hand which platforms currently support threading?
> BTW, I speak Win32 and some dialects of Unix, but I don't speak Mac

The threading API is supported in the following variations:

thread_atheos.h
thread_beos.h
thread_cthread.h
thread_lwp.h
thread_nt.h
thread_os2.h
thread_pth.h
thread_pthread.h
thread_sgi.h
thread_solaris.h
thread_wince.h

Finding something that works on all these systems is really tricky.

Regards,
Martin