[Python-Dev] Slides from today's parallel/async Python talk

[Trent Nelson]

No, I haven't.  I'd lose the excellent Windows pairing of thread pool IO and overlapped IO facilities if I did that.

Not saying it isn't an option down the track for the generic "submit work" API though; that stuff will work against any thread pool without too much effort.

But for now, the fact that all I need to call is TrySubmitThreadpoolCallback and Windows does *everything* else is pretty handy.  Lets me concentrate on the problem instead of getting distracted by scaffolding.

This e-mail was sent from a wireless device. 

On 21 Mar 2013, at 05:53, "Sturla Molden" <sturla at molden.no> wrote:

> Den 14. mars 2013 kl. 23:23 skrev Trent Nelson <trent at snakebite.org>:
> 
>> 
>>   For the record, here are all the Windows calls I'm using that have
>>   no *direct* POSIX equivalent:
>> 
>>       Interlocked singly-linked lists:
>>           - InitializeSListHead()
>>           - InterlockedFlushSList()
>>           - QueryDepthSList()
>>           - InterlockedPushEntrySList()
>>           - InterlockedPushListSList()
>>           - InterlockedPopEntrySlist()
>> 
>>       Synchronisation and concurrency primitives:
>>           - Critical sections
>>               - InitializeCriticalSectionAndSpinCount()
>>               - EnterCriticalSection()
>>               - LeaveCriticalSection()
>>               - TryEnterCriticalSection()
>>           - Slim read/writer locks (some pthread implements have
>>             rwlocks)*:
>>               - InitializeSRWLock()
>>               - AcquireSRWLockShared()
>>               - AcquireSRWLockExclusive()
>>               - ReleaseSRWLockShared()
>>               - ReleaseSRWLockExclusive()
>>               - TryAcquireSRWLockExclusive()
>>               - TryAcquireSRWLockShared()
>>           - One-time initialization:
>>               - InitOnceBeginInitialize()
>>               - InitOnceComplete()
>>           - Generic event, signalling and wait facilities:
>>               - CreateEvent()
>>               - SetEvent()
>>               - WaitForSingleObject()
>>               - WaitForMultipleObjects()
>>               - SignalObjectAndWait()
>> 
>>       Native thread pool facilities:
>>           - TrySubmitThreadpoolCallback()
>>           - StartThreadpoolIo()
>>           - CloseThreadpoolIo()
>>           - CancelThreadpoolIo()
>>           - DisassociateCurrentThreadFromCallback()
>>           - CallbackMayRunLong()
>>           - CreateThreadpoolWait()
>>           - SetThreadpoolWait()
>> 
>>       Memory management:
>>           - HeapCreate()
>>           - HeapAlloc()
>>           - HeapDestroy()
>> 
>>       Structured Exception Handling (#ifdef Py_DEBUG):
>>           - __try/__except
>> 
>>       Sockets:
>>           - ConnectEx()
>>           - AcceptEx()
>>           - WSAEventSelect(FD_ACCEPT)
>>           - DisconnectEx(TF_REUSE_SOCKET)
>>           - Overlapped WSASend()
>>           - Overlapped WSARecv()
>> 
>> 
>>   Don't get me wrong, I grew up with UNIX and love it as much as the
>>   next guy, but you can't deny the usefulness of Windows' facilities
>>   for writing high-performance, multi-threaded IO code.  It's decades
>>   ahead of POSIX.  (Which is also why it bugs me when I see select()
>>   being used on Windows, or IOCP being used as if it were a poll-type
>>   "generic IO multiplexor" -- that's like having a Ferrari and speed
>>   limiting it to 5mph!)
>> 
>>   So, before any of this has a chance of working on Linux/BSD, a lot
>>   more scaffolding will need to be written to provide the things we
>>   get for free on Windows (threadpools being the biggest freebie).
>> 
>> 
>> 
> 
> 
> Have you considered using OpenMP instead of Windows API or POSIX threads directly? OpenMP gives you a thread pool and synchronization primitives for free as well, with no special code needed for Windows or POSIX. 
> 
> OpenBLAS (and GotoBLAS2) uses OpenMP to produce a thread pool on POSIX systems (and actually Windows API on Windows). The OpenMP portion of the C code is wrapped so it looks like sending an asynch task to a thread pool; the C code is not littered with OpenMP pragmas. If you need something like Windows threadpools on POSIX, just look at the BSD licensed OpenBLAS code. It is written to be scalable for the world's largest supercomputers (but also beautifully written and very easy to read).
> 
> Cython has code to register OpenMP threads as Python threads, in case that is needed. So that problem is also solved.
> 
> 
> Sturla
> 
> 
> 
> 
> 
> 
> 
>