more on light weight mutex

[joel at OARcorp.com (joel at OARcorp.com)]

On 3 Aug 1999, Ian Lance Taylor wrote:

>    Date: Tue, 3 Aug 1999 12:41:52 -0500 (CDT)
>    From: <joel at oarcorp.com>
> 
>    I would propose 3 lightweight wrappers for:
> 
>      + obtain, block forever
>      + obtain, timeout
>      + obtain, poll
> 
> On the x86, I would like the code which acquires a mutex to do
> something more or less like this (my x86 assembly skills are not
> great):
> 
> 	lock
> 	addl $1,0(%ebx)
> 	je	gotit
> 	call	lock
> gotit:	
> 
> In other words: use a processor supported interlock instruction to
> attempt to acquire the mutex (in this example an unlocked semaphore
> holds the value -1).  If that succeeds, fine.  If it fails, call a
> subroutine to wait, poll, or whatever.  This sequence is short enough
> that it can be done as inline assembler.

That is reasonable and would have higher payoff performance-wise but would
require more development effort than what I was proposing.  

My suggestion also covered a counting semaphore.

>    We may still need to put them in an object information table to make
>    something work but at first glance I don't see it being necessary.  The
>    "id" argument to _CORE_mutex_Seize is for the id of an object you are
>    waiting on. I will have to investigate to make sure about the requirement
>    for this information.
> 
> My personal preference is for mutexes to be very lightweight.  I don't
> need them to be listed in a table, and I don't need a name for them
> other than a pointer (this is actually generally the case for me--I
> never use the RTEMS calls to look up an object by name).

I will need to confirm this but I thought the information table was being
used on either the "delete a task waiting on a resource" or "delete a
resource that a task is waiting on" path.  But now that I am looking at it
closer, it does not appear to be the case.  

--joel