mike@SNOWHITE.CIS.UOGUELPH.CA (Buckaroo Banzai) (08/01/90)
Hi. I am having hassles with locks on a 4D-240 (under IRIX 3.2.1).
The online manual states that I can allocate 4096 hardware locks from each
arena that I have created, and if I ensure that the creator of the arena
allocates the locks (via 'usnewlock', of course), then many locks may be had
with no trouble.
Trouble starts when I 'sproc' some kids and have _them_ allocate some
locks from the same arena. Sometimes the locks are allocated pre-set (which
is an inconvenience), and sometimes the child silently dies inside 'usnewlock'
(which is downright rude). So my problem is this: who is the comedian here,
me or IRIX?
I have attached a small program that consistently demonstrates my problem
on my system. It allocates, excercises, and frees N (=100) locks twice: once
as the parent and once as the child. On my system the child dies (dbx
euphemises that to 'Process xxx (a.out) finished') while nabbing the 87th lock.
I have also tried the program on a 4D-20 (which implements locks in software),
and it works fine with any value of 'N' I have tried (up to almost 700, when
the arena becomes too small). So my fear and ignorance are currently aimed
at hardware locks and their management.
Which brings me to the whining phase of this message. What embarassing
assumptions am I making? Has anyone else had any similar experiences? Why
are different locks given out during the second run of TestLocks? Why do
these things always happen to me? Any and all comments are welcome, 'cause
I'm stuck real good.
Mike Chapman
mike@snowhite.cis.uoguelph.ca
-------------------cut me, mick----------------------------------------------
#include <stdio.h>
#include <ulocks.h> /* Don't forget to link -lmpc... */
#include <assert.h>
#define N 100 /* 200 and 1000 caused trouble, too. */
usptr_t *arena;
/*////////////////////////////////////*/
TestLocks()
{
int i;
ulock_t lock [N];
for(i = 0; i < N; i++) {
lock[i] = usnewlock(arena);
assert(lock[i] != NULL);
ussetlock(lock[i]);
usunsetlock(lock[i]);
fprintf(stderr, "Tested lock %3d, addr = %d.\n", i, lock[i]);
}
for(i = 0; i < N; i++)
usfreelock(lock[i], arena);
fprintf(stderr, "Lock test passed. oo-ra.\n");
}
/*////////////////////////////////////*/
Child()
{
TestLocks();
fprintf(stderr, "Child is done.\n");
}
/*////////////////////////////////////*/
main()
{
int status, i;
arena = usinit("arena");
assert(arena != NULL);
TestLocks();
status = sproc(Child, PR_SALL);
assert(status >= 0);
sleep(60);
printf("Parent is done.\n");
}jwag@moose.asd.sgi.com (Chris Wagner) (08/02/90)
In article <9008010609.AA18877@snowhite.cis.uoguelph.ca>, mike@SNOWHITE.CIS.UOGUELPH.CA (Buckaroo Banzai) writes: > > Hi. I am having hassles with locks on a 4D-240 (under IRIX 3.2.1). > The online manual states that I can allocate 4096 hardware locks from each > arena that I have created, and if I ensure that the creator of the arena > allocates the locks (via 'usnewlock', of course), then many locks may be had > with no trouble. > > Trouble starts when I 'sproc' some kids and have _them_ allocate some > locks from the same arena. Sometimes the locks are allocated pre-set (which > is an inconvenience), and sometimes the child silently dies inside 'usnewlock' > (which is downright rude). So my problem is this: who is the comedian here, > me or IRIX? > > I have attached a small program that consistently demonstrates my problem > on my system. It allocates, excercises, and frees N (=100) locks twice: once > as the parent and once as the child. On my system the child dies (dbx > euphemises that to 'Process xxx (a.out) finished') while nabbing the 87th lock. > I have also tried the program on a 4D-20 (which implements locks in software), > and it works fine with any value of 'N' I have tried (up to almost 700, when > the arena becomes too small). So my fear and ignorance are currently aimed > at hardware locks and their management. > > Which brings me to the whining phase of this message. What embarassing > assumptions am I making? Has anyone else had any similar experiences? Why > are different locks given out during the second run of TestLocks? Why do > these things always happen to me? Any and all comments are welcome, 'cause > I'm stuck real good. > > Mike Chapman > mike@snowhite.cis.uoguelph.ca Ack! I found 3 seperate bugs all helpgin to confuse Mike: 1) a bad cast in the library will result in not telling an error during usnewlock if no more locks can be allocated 2) a bug in the hardware lock driver will not allow sproced children to alloc new locks 3) a bug in deallocation means that some freed locks are not marked as freed, therefore the second pass requires more locks.... Work arounds - have master alloc ALL locks and do NOT free them! 3.3 contains the same bugs but we'll see if we can get in a couple of the fixes Chris Wagner