Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!moose.asd.sgi.com!jwag
From: jwag@moose.asd.sgi.com (Chris Wagner)
Newsgroups: comp.sys.sgi
Subject: Re: Problems with hardware lock allocation
Message-ID: <11258@odin.corp.sgi.com>
Date: 2 Aug 90 03:11:20 GMT
References: <9008010609.AA18877@snowhite.cis.uoguelph.ca>
Sender: news@odin.corp.sgi.com
Reply-To: jwag@moose.asd.sgi.com (Chris Wagner)
Organization: Silicon Graphics, Research & Development
Lines: 56

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