Producer-Consumer Tasking model in Ada?

General
1

Hi;

I’ve been doing some thinking that’s (way) above my pay grade :slight_smile:

I think I want to consider a producer that enqueues its results and a consumer that dequeues kind of like a well-managed UNIX/Linux pipe. There might be more than two types of tasks (maybe thee’s another queue with other processes in the middle). Is there any tooling for this concept in Ada or just one needs to just “do it”?

Thanks,
RBE

2

I don’t know what you mean by “tooling for this concept”.
That’s such a basic level thing, and highly dependent on particulars, that this is kind of like asking “is there any tooling for a client-server?” — Do you mean a framework? a set of templates? a wizard/knowledge-base parameterization system? …or something more particular, like the server (and client) stuff for, say, TCP/IP with AWS. Is it something a bit more niche, like running GOPHER and FTP servers? and so on.

Given the generality of your question, perhaps a set of task interfaces (producer, consumer, and processor [both]) would work for the general architecture. You could also do generics implementing the various “forms” of tasks. You could combine the two approaches: have a generic for producers, a generic for consumers (that takes the producer as a formal parameter), and the processor being one that presents both the presenter and consumer interfaces.

Sorry I can’t really be of more help.

3

The standard Containers include a couple of synchronized queues (e.g. the Unbounded one).

If you want to roll your own, you should really consider building round a protected type (ARM 9.4 ff). I can offer an example spec and body.

4

Unless you want to support a light runtime. Booch 83 components work on a light runtime simply by replacing the exceptions

5

You must clarify what do you mean: communication between tasks or between processes.

In Ada we usually have higher level communication models than pipes. E.g. if queues are used then queue elements are typed.

6

You might want to look at PragmARC.Concurrent_Pipeline. It’s not completely asynchronous, but could be made so fairly easily.