Re: pthread and perfly
Brian Corrie (bcorrie++at++cs.anu.edu.au)
Wed, 16 Dec 1998 09:48:11 +1100
>Marc Erich Latoschik wrote:
>[snip]
>> > > > Actually, Performer does not use sproc. It is implemented using an
>> > > > explicit shared storage model and fork (as opposed to implicit sharing
>> > > > and sproc). It does however use arenas for the sharing which are also
>> > > > incompatible with pthreads.
>> > > >
>> > > i thing we need a little more clarification on this point.
>> > > About a year ago i tried to use pthreads with performer 2.0 together
>> > > and...failed of
>> > > course. Now i do the same stuff again with Performer 2.2.
>> > > I launch a pthread for reading in tracker data in async fassion into a
>> > > ring buffer.
>> > > Then from my Update routine i just read the latest tracker data. And
>> > > surprisingly: it works!
>> > > And it uses pthreads and it uses Performer in any multiprocess mode. And
>> > > a collegue
>> > > of mine at a different institute uses pthreads too.
>> > > It seems to work aurprisingly well.
>> > > So now what is the case?
>> >
>> > What version of IRIX are you using? Prior to IRIX6.5 pthreads was
>> > implemented on sproc features and would work together. As of IRIX6.5,
>> > this is no longer the case. My guess is that you are not running on
>> > IRIX6.5 and hence your program works correctly.
>>
>> Before I just answered only to you Phil,
>> but i think it might be interesting to the perf community as well
>> So here again.
>> Yes i use Irix 6.2 and 6.4. I was about to migrate our primer demo host
>> to 6.5, now i got reason not doing it ;).
>> Well, are there plans to modify Performer in a future release to
>> work with pthreads? Now that there is some kind of MP standard
>> it would be nice to use it (especially when coding for different
>> hardware like we do).
>> Of course #ifdef IRIX <do nasty stuff> #endif will do the trick but
>> makes live kind of unnecessary complicated. For me the sproc
>> is more a relict when SGI were the only ones doing MP'ing.
>> What do you think? What are the future plans?
>
>There are no plans to move Performer to a pthreads base. To do so would
>break just about every application out there. Pthreads assumes implicit
>sharing and contains no support for the explicit shared memory model
>adopted by Performer. We'd still have to use arenas, but as I already
>stated, this doesn't work with pthreads.
This conversation is very interesting to some of us, so please do keep it
public. It seems to me that moving Performer to pthreads is not necessarily
the solution that we want anyway (as Phil states, it would require many
fundamental changes in many things). What would be REALLY nice is to have
versions of pthreads/sproc/multiprocessing that do not break each other. Does
SGI have any plans on fixing this problem???? We are in the same situation as
Jason - we are using the CAVE libraries (which are Performer based), a package
which is sproc based, and a package which is pthread based. Pthreads is
arguably the "way ahead" for multi-processing (especially portable
multi-processing), but doesn't work with either sproc or shared arenas. I see
that as a bit of a fundamental problem, no? Is there a techical problem why
they can not co-exist???
Any comments on whether SGI plans on fixing this would be GREATLY
appreciated... 8-)
Cheers (and Merry Xmas),
Brian
This archive was generated by hypermail 2.0b2
on Tue Dec 15 1998 - 14:48:30 PST