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

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

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message
news:5iGLh.26236$PF.18838@attbi_s21...
> Randy Brukardt wrote:
> >
> > 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.)
>
> The PragmARCs use
>
> protected type Handle
>     (Ceiling_Priority : System.Any_Priority := System.Default_Priority)
> is
>     pragma Priority (Ceiling_Priority);
>
> They're Ada 95, and have been compiled with at least 2 different
> compilers. The problem is, as you pointed out, the library can't know
> what an appropriate priority is. Only the client can know that, and this
> allows the client to specify it.
>
> Is there something wrong with this approach?

Nothing serious, but it's less than ideal:
(1) It complicates the interface; it makes the client worry about something
that they probably don't care about.
(2) It doesn't work for a protected interface (no discriminants);
(3) It doesn't work as well if the protected object is wrapped in a tagged
type, because tagged types can't have defaults on their discriminants -
meaning that it always has to be specified. This also applies to any
protected object that defines an interface (it can have discriminants, but
no defaults, as it is considered tagged).

I suspect that most libraries will fall into category (2) or (3) [the latter
because of the need for clean-up, or simply that not all operations need to
be protected]. In any case, it illustrates the difficulty of defining
general-purpose task-safe libraries. There are a lot of gotchas that don't
apply to single-tasking code.

                                    Randy.