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!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Advice, tasking and hardware Date: Wed, 25 May 2016 18:09:54 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 26 May 2016 01:06:22 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="48b46be33beed75863f69afa437f956b"; logging-data="10334"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181GPKLAi6GHZwLEkOqeO3F00CR1L9S8xQ=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> Cancel-Lock: sha1:GKklmZexuHU0MxAssHUy/QRrtDQ= Xref: news.eternal-september.org comp.lang.ada:30480 Date: 2016-05-25T18:09:54-07:00 List-Id: On 05/25/2016 02:24 PM, patrick@spellingbeewinnars.org wrote: > > I struggled to find a GUI binding I liked and I struggled to work with C. I > wanted to use Ada to avoid using C and I didn't understand C well. > > For the past few years I have been using GnuCOBOL. I absolutely love it. It > is much easier to interface to C with and it compiles to intermediate C so > it's easier to see what is happening rather then going from Ada to Assembly. > While the interfaces.COBOL package is quite outdated and does not have > knowledge of modern COBOL it does work well and I can mix the two languages. I'm not sure what you're getting at here. A compiler's intermediate code is usually of no interest to a developer. I've done more interfacing to C from Ada than I'd like, and it's usually straightforward. > I don't have any experience with tasking though and while I have many > examples of tasking in my books, none of them seem to call low level > functions such as drivers or driver-like functions. I am planning on using > the Linux-GPIB library. Every call to a subprogram in Ada, be it high-level or low-level, is made by a task. The elaboration and the the main-program subprogram are executed by the environment task. Any subprogram calls made, directly or indirectly, by the main program are made by the environment task. I see no reason why you should expect calls from user-defined tasks to be any different. > Spark doesn't use tasking, are there many dangers in using tasking with > hardware? SPARK 2014 includes Ravenscar tasking. (http://docs.adacore.com/spark2014-docs/html/lrm/tasks-and-synchronization.html) I don't know how you'd use tasking without hardware. Concurrent development is a superset of sequential development, and some who are competent at the latter have difficulty with the former, even after extensive experience. Deadlock and race conditions are common dangers if you don't understand concurrency (and sometimes if you do). > Would it be wise to wrap C driver calls in a protected object or are most > drivers in Linux thread safe and suitable for being called from different > threads? That will depend on the library you're binding to, and you should refer to its documentation. If in doubt, wrapping the calls in a PO will ensure they are made sequentially. -- Jeff Carter "He didn't get that nose from playing ping-pong." Never Give a Sucker an Even Break 110