Re: Two-stage suspend operations

[rieachus@comcast.net]

On Saturday, May 7, 2016 at 12:13:19 PM UTC-4, Simon Wright wrote:
>
>It turns out that the 20 kHz is in a separate processor from the main 
>application. 

>Nothing like an enthuse-potential-volunteers description of a project 
>for generating confusion.

 Good, fifty microseconds is not a lot of time with a full tasking system.

>> Note BTW, that the GNAT pragma specifically allows the protected 
>> objects that only run in the context of another task/thread, have a 
>> high enough priority not to be interrupted, and do not reference any 
>> lower priority protected objects. 

> Can you tell me where this is documented?

It really isn't. You have to know how you expect a particular PO to map to say the RMW instructions provided by your particular hardware.  If it does?  Fine.  If not you have work to do to figure out what is confusing the compiler, or where you are confused.

When someone goes to port the software to new hardware?  It may work "right out of the box", or they may need to find what the equivalent primitive is for the new hardware and how to get the compiler to see it their way. )-: 

> Also, there seems very little difference between using Lock_Free and 
> Atomic: you can't have entries, and, when 'Contents' is an array of 
> integers, 

> lock_free.adb:3:07: illegal body when Lock_Free given 
> lock_free.adb:3:58: type of "Contents" must support atomic operations

I know the issue of an array of integers not supporting atomic updates was discussed in the ARG, but I don't believe it was ever "fixed."  To map the issue from theory to actual hardware, there is no guarantee that integers (of whatever size) can be updated atomically without affecting adjacent array entries.  Hmmm.  Try:
 type Foo is aliased limited new Integer -- is that the right order?
 Bar: array (Integer range 1..10) of Foo;

Better may be an array of protected integers?    

> Only mono-processor at the moment.

In computer science almost everything used three numbers, zero, one, and many.  In this area the numbers are zero, one, and many.  It is difficult to generate a deadlock that requires two processors, but livelock situations are often dual-processor related, and starvation can easily occur with many processors.

> I didn't mention that we are using Ravenscar, I thought that precluded 
> deadlock?

One of those good news bad news things.  Ravenscar can show that your main program is deadlock free--as long as you make promises about the non-Ada code in things like device drivers and the OS.  Choosing the right OS or implementing on bare metal takes care of 99% of that. But gotchas can turn up anywhere.  For example a processor with microcode that was back-patching missing instructions so that they only caused interrupts once.  Finding the right set of compiler directives fixed that, but of course, the hardware documentation had no clue...