From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Asynchronous channels in Ada Date: Sat, 20 Feb 2016 10:54:15 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: LNA1TkTuMxfwTHzeJdi6nA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29574 Date: 2016-02-20T10:54:15+01:00 List-Id: On 2016-02-19 22:02, Hadrien Grasland wrote: > Some months ago, I had some fun learning Go (golang). I found in > particular its concurrency model, based on coroutines and pipe-like > communication channels, to be quite sound and representative of the way > I write task-parallel programs. My condolences... (:-)) Co-routine if you meant that, is a kind of synchronous call. As such it does not require a buffered communication channel with its counterparts. > Now, to an Ada programmer, coroutines and synchronous channels are not > particularly special. Coroutines map well to Ada tasks (although most > Ada tasking implementations are not as CPU- and memory-efficient); Tasks are greatly less efficient than co-routines, considered a single core, in order to make a comparable case of course. Co-routines on their part are very low-level and unsafe. If Ada had user-tasks implemented as co-routines that would be nice for some interesting cases, like implementation of heavy-duty servers and communication protocols. > On the other hand, asynchronous "buffered" channels are really a neat > abstraction for producer-consumer problems, Well, I would say, it is a *source* of producer-consumer problems, especially regarding QoS, topology issues (e.g. n-to-m connections), resource management etc, the list is almost infinite... > and I regularly end up > facing a problem where I wish I had some in Ada. I'm pretty convinced > that one could quite easily build a library-based Ada abstraction which > offers similar functionality, but better. Before trying it myself, > though, I'd like to check out here if you know of an open-source Ada > project which has already implemented something similar. > > The ideal intertask communication primitive which I am looking for is... > > * One-to-one (one-to-many raises plenty of implementation problems, is > not used nearly as often, and may be emulated using one-to-one) Quite often, actually. A non-blocking implementation of 1-n: http://www.dmitry-kazakov.de/ada/components.htm#Generic_Blackboard > * One-way (there are well-separated sender and recipient roles in the communication) > * FIFO (objects are received in the same order as they are sent) > * Type-safe (all data packets must be of the same type, which should > be selectable using a generic formal parameter for optimal abstraction > generality) > * Portable across architectures and Ada compilers > * Mostly asynchronous (sender does not block unless buffer is full, > recipient does not block unless buffer is empty) > * Interruptible (sender and recipient can terminate the communication) > * Exception-friendly (sender can notify recipient that an exception has occured) What exception? If publisher needs to notify the subscriber of anything it does so by posting corresponding data, that is. > * Blocking-safe (the only circumstance where a task can end up > blocking forever on a channel is if there is a task on the other end > that is permanently blocked too) > * Reference-counted (that's really the only sane memory management > policy for objects which are shared between two unrelated pieces of > tasking code) Hmm, for 1-1 communications there is little sense to have the buffer reference counted. Publisher and subscriber can be easily put in the buffer's scope that is. There are more interesting cases when publisher or subscriber can walk away at any time, but they are more related to 1-n cases. Or maybe you mean reference-counted data being sent. That does not make sense either, because data are marshaled. The only case when data can be reference-counted is when they cannot be or are too expensive to marshal. In that case you post a reference instead of data. But that is not the buffer's business. > * Devoid of dynamic memory allocation after initialization time > (unless the data packets being transmitted contain controlled > dynamically allocated data, of course) > > Anyone is aware of something like this that would already exist in the wild ? Yes, there are plenty. I have a lock-free implementation of non-blocking FIFO: http://www.dmitry-kazakov.de/ada/components.htm#Generic_FIFO and a blocking one extension of. http://www.dmitry-kazakov.de/ada/components.htm#Generic_FIFO.Signaled_FIFO You can put any of it into a reference-counted object: http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de