Re: [Pympi-users] pyMPI + threading
Status: Alpha
Brought to you by:
patmiller
From: Vinicius P. <vpe...@ic...> - 2006-11-17 22:12:43
|
Well, As I'm using LAM/MPI... if I make sure that access to MPI functions are serialized (ie no concurrent access to MPI functions) using python threading.Lock for example that should work fine? And in the case I'm doing blocking MPI calls, what about to change to a non-blocking and use thread.wait() and notify() to synchronize when a message has arrived... to allow other Python thread make progress. A Thread named Receiver would be in a busy waiting Loop on irecv(), and calling appropriate functions depends on Tag message... there would be no blocking recv()... the problem will be on synchronizing threads using events or conditions... these ideas seems viable? Vinicius On 11/17/06, Pat Miller <pat...@gm...> wrote: > On 11/17/06, Vinicius Petrucci <vpe...@ic...> wrote: > > "Python uses a global interpreter lock for thread safety. That global > > lock must be held by a thread before it can safely access Python > > objects." > > The Python thread model is really pretty weak. This is a weakness in > reference counted languages (the incref/decref's are critical sections). > One can think of Python threads as "co-routines" even though each > thread is built on top of a real POSIX or Windows thread. You can have > as many as you want (upto the thread limit), but only one operates > at a time. Every so many byte code operations, the threads context > switch. > > A routine that takes a long time (like a blocking I/O call) is supposed to > play nice and release the global interpreter lock (and subsequently reacquire > it before returning to the interpreter). > > With MPI, your mileage will vary. An MPI implementation is allowed to put > restrictions on the use of MPI with threads. A common restriction is to > force all MPI calls to be issued from the master thread. A somewhat > weaker one is that all MPI calls must come from the *same* thread. > Weaker still is that only one MPI call can be extant at a given time (presumes > that the user provides locking). > > So, to get back to Vinicius' question. If your MPI supports threads > (e.g. OpenMPI), > then pyMPI will work fine with threads. The Python global interpreter lock > will guarantee that only one thread is working with MPI at a time (unless you > write an extension that releases the global lock). The bad news is that > the current configuration will not allow you to get much thread parallelism > going on. If you have a blocking receive in one thread, it will hold the > global interpreter lock, so no other Python thread can make progress. > > I have been thinking about modifying pyMPI to release the global interpreter > lock on entry to a pyMPI routine. Then, one could write threaded routines > to have blocking calls. To prevent simultaneous MPI calls, the pyMPI > routines would then need to acquire a pyMPI global lock before making > a call. > > Bottom line: pyMPI will work safely with threads, but the co-routine nature > of Python threads might not allow it to work the way you think. > > Pat > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Pympi-users mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pympi-users > -- Vinicius Tavares Petrucci home page: http://www.ic.uff.br/~vpetrucci |