Re: Advice, tasking and hardware

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

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