Parallel Programming - m_sync Problem

Micah Altman micah at flobb4.csd.sgi.com
Thu Apr 18 07:56:08 AEST 1991


In <4924 at dftsrv.gsfc.nasa.gov> cindy at cesdis2.gsfc.nasa.gov (Cindy Starr) writes:



>     "When m_sync is called by each thread, it waits
>      at that point for all other threads to call
>      m_sync."
> 
>  This doesn't appear to be happening in my test
>  program below.  Does anyone know why?

Actually, I believe m_sync is working just fine. I think the reason
things _appear_ to be screwy is that when you do a printf()
across multiple threads you'll see the results in a very arbitrary
order ( depending on timing  of the printf , internal sempahores and
file flushing ).

In your test program instead of doing something like this:

	printf("Syncing....
	m_sync();

Do this:
	m_sync();
	printf(" Synced and released ");
	fflush();
	m_sync();

And you'll see that all the threads are released at the same time...
( You do the second sync to make sure every thread has printed out and flushed
the message, before every thread can continue. )

> 
>  Also, are there any problems in using the Sequent
>  routines (m_...) together with the lock & semaphore
>  routines (us..) and area routines (a..)? Has anyone

No problem mixing m_* and us* routines. I don't know about the
amalloc calls, use the usmalloc calls instead.


>  seen any documentation on the task routines other
>  than the man pages?  They don't seem to be in my
>  version of the parallel programming manual. 
> 

You may want to avoid the task* stuff, I thinks its going away in
the next release- though I'm not positive on this.

>  If anyone has SHORT examples of using the parallel
>  programming library, they'd be a great help!

Also, there is a class in Parallel Programming offered by SGI , you 
can call 1-800-800-4SGI to get details.
--
	"Entia non sunt multiplicanda sine necessitate." - William of Ockham
	Micah Altman, "Computational Juggler"	   	   micah at csd.sgi.com
	Phone (415) 335-1866				   FAX (415) 965-2309
	Disclaimer: 	Everything in this document is a lie.	



More information about the Comp.sys.sgi mailing list