Jim Parsons (jparsons++at++ist.ucf.edu)
Wed, 9 Oct 1996 13:50:18 -0400 (EDT)
2) I don't use 'usinitlock', just 'usnewlock'. My Shared struct
contains an array of locks which I initialize like this:
for( i=0; i < MAX_FOB_TRACKER; i++ )
{
Shared->FOBcoord_lock[i] = usnewlock(pfGetSemaArena());
if( !Shared->FOBcoord_lock[i] )
{
perror("FOBmgr could not allocate a lock");
exit(0);
}
}
Now my parent process and the sensor process both use the
typical ussetlock - usunsetlock calls to write and access data.
When I have an experiment (simulation) set to go, I use the
sysmp call with MP_MUSTRUN to assert that it runs on processor 0 of
my 4 processor onyx, along with the scheduler, etc. while app, cull,
and draw run on processors 1,2, and 3. A kind of load balancing...
Hope this helps,
Jim
On Wed, 9 Oct 1996, Greg Newton wrote:
>
> I am having a problem trying to use shared arena locks within a Performer
> program. I'm using Performer 2.0 and have run into this problem on an IR, a
> Max Impact and on a Solid Impact, all running IRIX 6.2.
>
> I have a fastrak class that sprocs off a reader process to read the data from
> the serial port. The class has a lock that I want to use to ensure mutual
> exclusion when updating or reading some member variables that contain the
> position and rotation info.
>
> Here's how I allocate the lock :
>
> // =========================================
>
> void* semaArena = pfGetSemaArena();
> if (!arena)
> return 0;
>
> mutex = usnewlock(arena);
> if (!mutex)
> return 0;
>
> usinitlock(mutex);
>
> // =========================================
>
> It is always allocated and initialized okay.
>
>
> When I'm ready to write to the member variables, I make the following call :
>
> ussetlock(mutex);
>
> I've checked the return value for ussetlock and it's always 1, indicating that
> the lock was acquired.
>
> I then write to a few variables and make the following call to unlock the lock
> :
>
> usunsetlock(mutex);
>
> Here's where the problem arises. My program core dumps when the usunsetlock
> function is called. According to cvd, it dies at
> _r4kup_unsetlock()["r4k.s":243, 0x0fa3cce4]
>
>
> The lock is valid and was acquired so I don't understand what could be causing
> this. I use the same locking/unlocking methods in other programs that don't
> use Performer and never have any problems.
>
> Anybody have any suggestions?
>
> Thanks,
> Greg
>
>
>
> --
>
> _______________________________________________________________________________
> Greg Newton Graphics, Visualization & Usability Center
> M.S. Student College of Computing
> gregn++at++cc.gatech.edu Georgia Institute of Technology
> http://www.cc.gatech.edu/people/home/gregn (404) 894-9635
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:45 PDT