Re: [RFC] New locking primitive for 2.5

[yodaiken@fsmlabs.com]

On Thu, Feb 07, 2002 at 09:57:35PM +0100, Daniel Phillips wrote:
> On February 7, 2002 09:36 pm, yodaiken@fsmlabs.com wrote:
> > > P.S. If this is going to turn into another priority-inheritance flame, I
> > > am stopping here.  Let's take it off-list or just drop it, please.  I'd
> > > much prefer to discuss the current combilock issue which is at hand. ;)
> > 
> > It's the same issue.
> 
> Not necessarily, look at Ingo's observation about replacing semaphores with 
> combi-locks as opposed to replacing spinlocks with combi-locks.

The underlying issue is an attempt to find a magic trick that will make
hard synchronization problems go away. The result is usually something that
makes hard synchronization problems more obscure. Ingo points to a case,
apparently triggered only by a wierd benchmark artefact where a queue of very
short term operations builds up a queue of expensive process reschedules. The
problem is that the same semaphore is used to for slow and fast operations
and the solution is to split them apart somehow or to conclude that its not
an important case. 

As Ingo points out, you need some actual positive results here, not a plausibility
argument.


-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com