Re: Arguments for single-mutex-exclusion on protected types (Was: Does Ada tasking profit from multi-core cpus?)

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccmz2azb7j.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > I don't understand Jeffrey's point either, but isn't it true that
ceiling
> > locking is essentially irrelevant on multiprocessor systems? That is,
the
> > point is to get rid of the lock, but you can't do that on a
multi-processor
> > (one processor can be running a lower priority task without anything
being
> > wrong, and that task had better be blocked from accessing the protected
> > object). So ceiling locking has no advantage on a multi processor, it
just
> > restricts what you can do. If multiple cores continue to grow in
popularity,
> > it seems that the whole ceiling locking thing will become essentially
> > irrelevant - just another case of premature optimization.
> >
> > (Can you tell I don't like ceiling locking much??)
>
> On a multiprocessor, you can use ceilings plus spin locks to protect
> protected objects.  The point is to avoid any queued waiting to enter a
> PO (all the queuing is done with entry queues in this model).  That can
> be made quite efficient, and the ceilings still prevent certain forms of
> priority inversion.  So, no, I don't think ceilings are entirely
> irrelevant on multiprocessors.

I believe that latter point (ceiling prevent some forms of priority
inversion, because they boost the priority of everything in the PO), but I
don't see the former. I don't see any reason that you would have to use a
queued (rather than a spin) lock with or without ceiling locking. Until you
have the spin lock, your priority doesn't matter (if you get pre-empted, so
what?). And afterwards, it's just a special case of the normal potential
priority inversion of a PO: if it isn't an issue for the entire object
(assuming you can start a protected action), it surely won't matter how you
start that action.

The problem with ceiling locking is that it depends on boosting the priority
of tasks. That means its a big problem for longer-running operations (such
as I/O, which aren't allowed in protected operations for this reason). And
it's a big problem for reusable libraries, which can't know ahead of time
what the ceiling ought to be. (Make it too high, and critical tasks could be
starved by lower-priority ones operating in the library, make it too low and
tasks aren't even allowed to access the library.) Consider trying to set the
ceiling for a container library implemented with protected objects. (At
least we now can do this on the fly; in Ada 95, it was impossible.)

> Ceilings are largely irrelevant if you're building Ada tasking on top of
> some other system (posix or windows threads, for example) that wants to
> do things differently.  I mean, if you're using the
> one-Ada-task-per-thread model.

Is there any other kind? I haven't heard of many bare-machine Ada projects
in recent years; almost everything is on top of some sort of RTOS or other
OS. (That's too bad, really, for a lot of projects, Ada provides nearly
everything you need in an RTOS.)

> Another issue is that Ada's priority model has nothing to say about
> processor affinity.

True enough, but I don't think most OSes have much to say on this topic,
either. That makes it pretty hard to say anything about it (unless you use a
one-thread for all tasks model -- but that's a pessimising implementation!)

                                    Randy.