Re: Newbie question about generic linked list tasks

[farrell@coral.cs.jcu.edu.au (John Farrell)]

In <EACHUS.94Sep23105307@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article <farrell.780237190@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:
>  > I would like more concurrency than just semaphores gives you.
>   Hmmm... The semaphores don't "grant" concurrency, they just allow
>constructs to remain consistant even if concurrency is present.  In
>constructing a concurrent application, you have to decide which
>threads should be active, and which can be passive.  Usually lists are
>treated as passive.  But that is another topic.

  Well, it's an interesting topic to me. Active lists sound like fun. I got
the implementation with the binary semaphores working, only to discover that
after I had created a couple of hundred lists I reached a task limit :-(.
I spent two hours searching books saying "TASKING_ERROR, there can't be a
TASKING_ERROR in there!".

>>    And what if I wanted to do a list traversal? I would have to
>> pass a procedure/function to operate on items as a generic, but I
>> don't believe I can pass them into an entry, so they would have to
>> be generic for the package.  Then I only have one traversal
>> function for each instantiation of the package?

>   ...you will need primitive (and hidden) entries to the task type to
>give you a handle into the list, and operations on it, say:
>   entry Get_Handle(H: out Handle);
>   entry Free_Handle(H: in out Handle);
>   entry Next(H: in out Handle; I: out Item);
>   entry At_End(H: in Handle; Done: out Boolean);
>   (At_End is provided, but you would probably want to depend on Next
>raising an exception at the end of the list.)  Now your list package
>can export a generic traversal operation which takes a generic formal
>procedure parameter.  If you code it right, you can even have several
>traversals of the same list in progress at the same time.  

  So while I have a handle on the list, nothing else can access it? Hmmm, no,
while I have a handle on the list, no other task which started access after I
did can modify the current element or any later element. Cool!

>If you
>really want to do that, you might want two generic traversals, one
>which allows only read access to list elements, and one which provides
>read/write:

  Yep, my current package has a traverse procedure which applies a procedure
taking an in out to each element, and a traverse function which makes a new
list gotten by applying the function to each element.

> > What do you mean by completion?
>   The full declaration which conforms to the private type declaration
>and completes it.

  Ta.

>    Hope the above helps.  

  Yes, I'm inspired.

>It is possible to do what you want in Ada
>83, but the private part of the package (and the body!) start getting
>messy.  

  Oh, you mean I gotta learn 9X now? Didn't they get perverts like me to do
this sort of stuff back when they invented Ada? I read one book ("Studies in
Ada Style": Hibbard, Hisgen, Rosenberg, Shaw, Sherman) which allegedly studies
the possibilities of the Ada design, before compilers had actually been
implemented. The examples are like something from a second year data
structures course, there is nothing tricky in there at all.

>If you get too fancy, you end up writing the body of the task
>type as a finite state machine, with eight or nine accept statements
>or altenatives for each entry.  (I know, I've done it, and multi-page
>task bodies are a bitch to test.)

  Blagh. I have been writing Gofer (a functional language) for 2 years now for
my everyday needs and for this class, and I have been writing Ada for say 3
months purely for this class. I can find ~2500 lines of Gofer and ~1400 lines
of Ada. Considering how much I have achieved in Gofer and how little I have
achieved in Ada, I have to have serious doubts about the contribution of Ada
to software engineering! I have not previously been an evangelistic functional
programmer, but Ada is changing my mind :-).


John