Thread: Re: [Pympi-users] pyMPI + threading
Status: Alpha
Brought to you by:
patmiller
From: Julian C. <jul...@ya...> - 2006-11-17 00:12:58
|
I think one of the major issues here is python itself. Are you thinking=0Ao= f using threads within python? Python itself has an interpreter lock=0Athat= effectively prevents python threads executing simultaneously (you=0Amay al= ready be aware of this).=0A=0APat Miller would be better qualified to comme= nt on the availablity of MPI_THREAD_MULTIPLE itself.=0A=0Aregards=0A=0AJuli= an Cook=0A=0A=0A----- Original Message ----=0AFrom: Vinicius Petrucci <vpet= ru...@ic...>=0ATo: pym...@li...=0ASent: Thursday, = November 16, 2006 6:30:54 PM=0ASubject: [Pympi-users] pyMPI + threading=0A= =0AHi all!=0A=0ApyMPI with threading support works alright? is it stable? w= ith open=0Ampi for example...=0A=0Ais it possible to use MPI_THREAD_MULTIPL= E... or what ? is there any limitation?=0A=0Aif not, could you send me some= tips on how to use python + mpi +=0Athreading in a safe manner? or some ex= amples? any experience in this=0Aissue is worth.=0A=0AI was thinking about = some design decision:=0A* use a Lock to provide exclusive access to mpi fun= ctions=0A* 1 thread in loop, executing "req =3D irecv()" and when some msg = with a=0Atype of TAG is available, it calls an appropriate function. it can= use=0Asome send functions inside too.=0A* other thread making some send ca= lls...=0A=0Awhat common mistakes should I avoid?=0A=0Athanks in advance!=0A= =0A=0A-- =0AVinicius Tavares Petrucci=0Ahome page: http://www.ic.uff.br/~vp= etrucci=0A=0A--------------------------------------------------------------= -----------=0ATake Surveys. Earn Cash. Influence the Future of IT=0AJoin So= urceForge.net's Techsay panel and you'll get the chance to share your=0Aopi= nions on IT & business topics through brief surveys - and earn cash=0Ahttp:= //www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV= =0A_______________________________________________=0APympi-users mailing li= st=0AP...@li...=0Ahttps://lists.sourceforge.net/list= s/listinfo/pympi-users=0A=0A=0A=0A=0A=0A=0A=0A =0A_________________________= ___________________________________________________________=0ASponsored Lin= k=0A=0AMortgage rates near 39yr lows. =0A$310k for $999/mo. Calculate new p= ayment! =0Awww.LowerMyBills.com/lre |
From: Vinicius P. <vpe...@ic...> - 2006-11-17 10:52:28
Attachments:
naimi7.py
|
Hi Julian... Hmm... i've heard about this python Lock... "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." So, is it safe to call MPI functions (though pyMPI) by two simultaneous threads in python? I'm using threading python library and LAM/mpi runtime + pyMPI. I've attached a simple code in Python to explain better. it seems to run alright. but as it is an long term project that will be based on this simple one, I really want to make sure that I'm not going in wrong way choosing threads + mpi and in future get stuck with impossible to debug kinds of errors... Regards, Vinicius On 11/16/06, Julian Cook <jul...@ya...> wrote: > > > I think one of the major issues here is python itself. Are you thinking of > using threads within python? Python itself has an interpreter lock that > effectively prevents python threads executing simultaneously (you may > already be aware of this). > > Pat Miller would be better qualified to comment on the availablity of > MPI_THREAD_MULTIPLE itself. > > regards > > Julian Cook > > > ----- Original Message ---- > From: Vinicius Petrucci <vpe...@ic...> > To: pym...@li... > Sent: Thursday, November 16, 2006 6:30:54 PM > Subject: [Pympi-users] pyMPI + threading > > Hi all! > > pyMPI with threading support works alright? is it stable? with open > mpi for example... > > is it possible to use MPI_THREAD_MULTIPLE... or what ? is there any > limitation? > > if not, could you send me some tips on how to use python + mpi + > threading in a safe manner? or some examples? any experience in this > issue is worth. > > I was thinking about some design decision: > * use a Lock to provide exclusive access to mpi functions > * 1 thread in loop, executing "req = irecv()" and when some msg with a > type of TAG is available, it calls an appropriate function. it can use > some send functions inside too. > * other thread making some send calls... > > what common mistakes should I avoid? > > thanks in advance! > > > -- > Vinicius Tavares Petrucci > home page: http://www.ic.uff.br/~vpetrucci > > ------------------------------------------------------------------------- > 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 > > > ________________________________ > Sponsored Link > > Mortgage rates near 39yr lows. $310,000 Mortgage for $999/mo - Calculate new > house payment > ------------------------------------------------------------------------- > 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 |
From: Pat M. <pat...@gm...> - 2006-11-17 14:04:10
|
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 |
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 |