Re: RFC: Prototype for a user threading library in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:du69ugF3631U1@mid.individual.net...
> On 16-07-07 03:32 , Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:nliir0$1a7l$1@gioia.aioe.org...
>>> On 05/07/2016 23:53, Randy Brukardt wrote:
>> ...
>>>> Nothing in the core language of Ada requires tasks to be pre-emptive.
>>>
>>> Some applications rely on time sharing and most do on close to instant
>>> switching to a task of higher priority.
>>
>> Priorities are evil and almost always used poorly, that is to do 
>> something
>> that should be accomplished explicitly with locking or the like. No 
>> system
>> I'm contemplating has any priorities.
>
> Are you not contemplating any real-time systems? If you are, what do you 
> use instead of priorites, to ensure that urgent activities are done in 
> time?

I'm not contemplating hard-real-time systems (under 10ms response time). I 
don't think it is possible to create implementation-independent code for 
those sorts of deadlines, and as such it doesn't really matter from a 
language perspective how that's done (it won't be portable in any case).

I'm unconvinced that the way to ensure that "urgent activies" are done is 
some sort of magic (and priorities are essentially magic). I'd rather make 
sure that no task is hogging the system, and avoid overcommitting. That 
usually happens naturally, and in the unusual case where it doesn't, there's 
almost always someplace where adding a synchronization point (usually a 
"Yield" aka delay 0.0) fixes the problem. [Most of the cases have involved 
I/O, and the system I've been discussing with Dmitry would pretty much have 
eliminated that. We had considered adding synchronization points to loops 
many years back, but couldn't figure out how to do that cheaply enough to be 
useful (the MS-DOS clock was much too expensive) - that could be revisited 
if necessary].

It might actually be possible to make this system work with some form of 
priorities (we have them in our task supervisor, we just have the range of 
priorities set to 1 so that preemption doesn't come into play). That would 
certainly require the compiler to break loop and call cycles with 
synchronization points, and whether that could be done without visible 
performance impact is definitely TBD. (And I don't want to make my head hurt 
worrying about priorities when just getting task mapping to work is complex 
enough.)

                                   Randy.