Re: Ada Protected Object Tutorial #1

[Laurent Guerby <guerby@acm.org>]

kaz@ashi.footprints.net (Kaz Kylheku) writes:
> POSIX is an interface which can also be implemented such that it
> handles common situations without calling into an operating system.
> A trivial example of that would be seizing a pthread_mutex_t lock
> when there is no contention.  The POSIX threading functions are not
> necessarily system calls.
> 
> Just because something is not built into the language syntax, and
> the name of its specification rhymes with UNIX doesn't mean that
> it's a call into the opearting system.

I believe what Steve said had nothing to do at all with the
implementation of POSIX as system calls or whatever, he was talking
semantics. Some seemingly simple Ada concurrency constructs can lead
to a very complex POSIX calls/lock/condition scheme, complex not
necessarily meaning inefficient implementation in this context, just
that some of the semantic complexity is taken care of by your
implementation.

> The protected types as described are utterly useless to me because
> of the limitations of what they can do. I can't think of any
> software I have written in the past two years in which protected
> types could have been applied (had I been working in Ada). In almost
> everything I have done, there are complex relationship among the
> collaborating objects. There are calls among the objects from within
> critical regions, as well as condition waits in arbitrary places.

I believe you know about the Ada requeue statement (9.5.4) if you're
talking about collaborating objects, right?

> The fact is, if you have a thread running on another processor that
> is about to seize a lock, and you have to suspend that thread
> because the current owner is passing ownership of the lock to some
> specific thread, that is a waste of processor time.

One thing you're missing is that with protected objects and the Ada
queue/barrier model there is no mandatory unlocking/relocking involved
when there is "contention". The implementation can use same thread
that made the condition true for other threads to continue service
other threads that were blocked on an entry with a flase barrier.

- at t=t0, T1 is inside PO.S1, T2 is blocked on PO.S2 with barrier B2.

- at t=t1, T1 finishes PO.S1 code, the Ada runtime still in T1 context
reevaluate B2, finds it true and will execute PO.S2 still witin T1 context
at the end of PO.S2 code, T2 is released and T1 thread might continue
to do other things on PO.

Note here that it is one implementation model, but it is not the only
one, an implementation is free to do "inefficient" locking/unlocking
all over the place, or to use one or more internal thread to execute
PO code if it believes it is more efficient.

RM 9.5.3:

RM> 22 An implementation may perform the sequence of steps of a protected
RM> action using any thread of control; it need not be that of the task
RM> that started the protected action.  If an entry_body completes without
RM> requeuing, then the corresponding calling task may be made ready
RM> without waiting for the entire protected action to complete.
RM> 
RM> 	  22.a Reason: These permissions are intended to allow
RM> 	  flexibility for implementations on multiprocessors.  On a
RM> 	  monoprocessor, which thread of control executes the protected
RM> 	  action is essentially invisible, since the thread is not
RM> 	  abortable in any case, and the "current_task" function is not
RM> 	  guaranteed to work during a protected action (see C.7).

> I'd like to hear from somone who has experience with these so-called
> protected types on a machine with 16 processors or more. What is the
> scalability like of existing implementations?

As for anything related to performance, you have to provide a specific
benchmark that defines what "scalability" you are talking about here,
otherwise we'll be stuck in meaningless discussions. 

Also assuming that the Ada implementation uses POSIX thread, you can
always at least get the same "scalability" (if it proves to be good)
by coding directly your POSIX calls the way the Ada implementation
does, but then you'll probably get a more meaningful comparison by
looking at the POSIX vs Ada complexity of code.

Also I believe your experience is exceptional with super-complex
concurrent systems, what are you implementating for a living?

--LG