On 2021-12-09 19:28, EricP wrote:
> Niklas Holsti wrote:
>> On 2021-12-09 0:43, EricP wrote:
>>
>>> task Handler is
>>>    entry Receive_AST (astParm : Integer);
>>>    pragma AST_ENTRY (Receive_AST);
>>> end Handler;
>>>
>>> task body Handler is
>>>    accept Receive_AST (astParm : Integer) do
>>>    ...
>>>    end Receive_AST;
>>> end Handler;
>>>
>>>    ...
>>>    QIO (..., ASTADDR => Receive_AST, ASTPRM => 33);
>>>
>>> What is lost here is that it takes an AST which acts like a thread
>>> interrupt and turns it into something that is delivered by polling.
>>
>> A task waiting at an accept is not "polling", IMO, even if the accept
>> statement has a time-out so that the task can periodically or
>> sporadically do something else in between waiting.
>
> If either the entry or accept statement has a time-out I consider
> that a polling interface as it is checking for a condition then
> doing something else, pretty much the definition of busy-waiting.

Your definition of busy-waiting is strange. Suppose the accept has a
time-out of one second, because the task has to record a short status
message once per second, taking, say, 1 ms of processing time. Then, if
no-one calls the entry, the task is busy only 1 ms per second, _and_
doing useful (required) work for that 1 ms.

My definition of busy-waiting is waiting that consumes processor time
without doing any useful work during the wait, which is not the case for
accepts with time-outs.

On Thursday, December 9, 2021 at 11:33:58 AM UTC-6, EricP wrote:
> Niklas Holsti wrote:
> > On 2021-12-09 0:43, EricP wrote:
> >
> >> task Handler is
> >> entry Receive_AST (astParm : Integer);
> >> pragma AST_ENTRY (Receive_AST);
> >> end Handler;
> >>
> >> task body Handler is
> >> accept Receive_AST (astParm : Integer) do
> >> ...
> >> end Receive_AST;
> >> end Handler;
> >>
> >> ...
> >> QIO (..., ASTADDR => Receive_AST, ASTPRM => 33);
> >>
> >> What is lost here is that it takes an AST which acts like a thread
> >> interrupt and turns it into something that is delivered by polling.
> >
> > A task waiting at an accept is not "polling", IMO, even if the accept
> > statement has a time-out so that the task can periodically or
> > sporadically do something else in between waiting.
<
> If either the entry or accept statement has a time-out I consider
> that a polling interface as it is checking for a condition then
> doing something else, pretty much the definition of busy-waiting.
<
I don' know about that.
<
Consider a block of code with 3 accept entries and a delay.
<
Why is this not a 4 entry accept where the 4th entry is connected
to a timer event not an accept event ?
<
>
> Granted the above example code does not so the task would wait at
> accept until an AST arrived. However a more realistic example using
> asynch IO would do other things while the IO is outstanding,
> so in practice the above would have a time-out to poll the accept.
> >> These are not interchangeable concepts - you can't do a proper SIGINT
> >> or SIGKILL that is only delivered by polling.
> >
> > What is "proper" is subjective and depends on the requirements for
> > whatever you are implementing -- requirements on reaction time, clean-up
> > and last-wish actions.
> Those signals are expected to be delivered to the target thread using
> interrupt semantics. If they are not the behavior difference is noticeable.
>
> For example, if a terminal interface wants a CTRL-C handler,
> and the interface for CTRL-C is through accept statements,
> then this would have to be accepts with delay=0 which would
> have to be polled by the terminal handler code
> (otherwise the interface would appear to hang).
>
> That is not the same behavior as a signal delivered to a thread via
> interrupt semantics because, for example, it won't break into an
> infinite loop as an interrupt would.

On 12/9/21 1:30 AM, Ivan Godard wrote:
> On 12/8/2021 4:41 PM, Bakul Shah wrote:
>> I think of a Mill portal call as continuing in the *same* thread
>> but in a different turf (protection domain). This is analogous to
>> a system call on current OSes that continues in the same thread
>> but in a higher privilege domain (which makes it inherently less
>> secure - but that is a different discussion thread!). I do think
>> Mill got this exactly right. At least conceptually it is the
>> "same stack" but different segments are in different turfs.
>
> It's a matter of definition - just what is a "thread"? If you interrupt
> a running program, are you in the same thread even though you are doing
> work completely unrelated to what was being done before? Or are you in a
> completely different thread that has hijacked a random stack?

My definition: a thread of control. If there is a trap (syscall,
some instruction fault, or a page-fault), you are still in the same
thread but in a different protection domain (supervisor). If there
is an interrupt, the original thread stops running but it is not put
on the ready queue (that is, managed by the OS scheduler) since the
ISR can iret to it. What kind of beast the interrupt handling code is,
is what we are arguing about :-)

>
> Remember TSRs? Are they pending threads, or or function libraries?at
>
>>> Your concern for the cost of context switch is a bit outdated. Both
>>> M66 and Mill can do a switch in the time of a legacy call, though
>>> using different methods, and there are other ways available too. The
>>> critical thing is to design context switch as a first class operation
>>> from the beginning.
>>
>> Agree in principle but this is somewhat independent of how
>> interrupts can be handled!
>>
>> Does Mill allow a context switch from thread A in turf T
>> to an unrelated thread B in turf U? I thought it was more
>> of a Manhattan geometry: you switch turfs in the same thread
>> or switch threads in the same turf.
>
> The former; that's what portal calls do. But that doesn't switch stack
> or core, just context. Or not, depending on what you mean by a thread. >
> If a thread is defined as a nesting call sequence, then a portal call
> does not change thread - the return from a portal call puts you in the
> caller. If a thread is an addressing (scope) sequence (downstack links
> for example, for any language with proper static nesting of functions)
> then a portal call does change thread, although it is up to the language
> implementation to ensure the links are right - the Mill guarantees
> correct secure visibility, but doesn't make you look :-)
>
>> I should post a separate article on my mental model of ideal
>> interrupt handling....
>
> You should. Or at least post it to the Mill dev list :-)

I am writing one but this is going to take some time.

On Thursday, December 9, 2021 at 5:53:45 PM UTC-6, Bakul Shah wrote:
> On 12/9/21 1:30 AM, Ivan Godard wrote:
> > On 12/8/2021 4:41 PM, Bakul Shah wrote:
> >> I think of a Mill portal call as continuing in the *same* thread
> >> but in a different turf (protection domain). This is analogous to
> >> a system call on current OSes that continues in the same thread
> >> but in a higher privilege domain (which makes it inherently less
> >> secure - but that is a different discussion thread!). I do think
> >> Mill got this exactly right. At least conceptually it is the
> >> "same stack" but different segments are in different turfs.
> >
> > It's a matter of definition - just what is a "thread"? If you interrupt
> > a running program, are you in the same thread even though you are doing
> > work completely unrelated to what was being done before? Or are you in a
> > completely different thread that has hijacked a random stack?
<
> My definition: a thread of control. If there is a trap (syscall,
> some instruction fault, or a page-fault), you are still in the same
> thread but in a different protection domain (supervisor).
<
What do you call it when the trap handler executes on a different core than
the trap initiator ?
<
> If there
> is an interrupt, the original thread stops running but it is not put
> on the ready queue (that is, managed by the OS scheduler) since the
> ISR can iret to it. What kind of beast the interrupt handling code is,
> is what we are arguing about :-)
> >
> > Remember TSRs? Are they pending threads, or or function libraries?at
> >
> >>> Your concern for the cost of context switch is a bit outdated. Both
> >>> M66 and Mill can do a switch in the time of a legacy call, though
> >>> using different methods, and there are other ways available too. The
> >>> critical thing is to design context switch as a first class operation
> >>> from the beginning.
> >>
> >> Agree in principle but this is somewhat independent of how
> >> interrupts can be handled!
> >>
> >> Does Mill allow a context switch from thread A in turf T
> >> to an unrelated thread B in turf U? I thought it was more
> >> of a Manhattan geometry: you switch turfs in the same thread
> >> or switch threads in the same turf.
> >
> > The former; that's what portal calls do. But that doesn't switch stack
> > or core, just context. Or not, depending on what you mean by a thread. >
> > If a thread is defined as a nesting call sequence, then a portal call
> > does not change thread - the return from a portal call puts you in the
> > caller. If a thread is an addressing (scope) sequence (downstack links
> > for example, for any language with proper static nesting of functions)
> > then a portal call does change thread, although it is up to the language
> > implementation to ensure the links are right - the Mill guarantees
> > correct secure visibility, but doesn't make you look :-)
> >
> >> I should post a separate article on my mental model of ideal
> >> interrupt handling....
> >
> > You should. Or at least post it to the Mill dev list :-)
> I am writing one but this is going to take some time.

Niklas Holsti wrote:
> On 2021-12-09 19:28, EricP wrote:
>> Niklas Holsti wrote:
>>> On 2021-12-09 0:43, EricP wrote:
>>>>
>>>> What is lost here is that it takes an AST which acts like a thread
>>>> interrupt and turns it into something that is delivered by polling.
>>>
>>> A task waiting at an accept is not "polling", IMO, even if the accept
>>> statement has a time-out so that the task can periodically or
>>> sporadically do something else in between waiting.
>>
>> If either the entry or accept statement has a time-out I consider
>> that a polling interface as it is checking for a condition then
>> doing something else, pretty much the definition of busy-waiting.
>
>
> Your definition of busy-waiting is strange. Suppose the accept has a
> time-out of one second, because the task has to record a short status
> message once per second, taking, say, 1 ms of processing time. Then, if
> no-one calls the entry, the task is busy only 1 ms per second, _and_
> doing useful (required) work for that 1 ms.
>
> My definition of busy-waiting is waiting that consumes processor time
> without doing any useful work during the wait, which is not the case for
> accepts with time-outs.

My definition is based on differences in cost and synchronization.

The word poll means to collect a sample of values, usually opinions.
For computer interfaces poll means repeatedly sampling the state of
something to detect a change. What one does between samples is irrelevant.
Sitting in a nop loop reading a device register is polling,
but it also would be if it processed work between samples.

The alternative is interrupt semantics - being informed when a
state actually has changed.

Polling uses resources to continuously check for changes and increases
in cost as number of samples scales up, whereas interrupts do not.
But interrupts having significant synchronization and race condition
issues that polling does not.

> The alternative is interrupt semantics - being informed when a
> state actually has changed.

Of course, interrupts are handled by having the CPU poll the interrupt
line(s) every cycle or so ;-)

> Polling uses resources to continuously check for changes and increases
> in cost as number of samples scales up, whereas interrupts do not.

It's only that the polling done to handle interrupts is super cheap.

> But interrupts having significant synchronization and race condition
> issues that polling does not.

Indeed. Software often implements a form of polling on top of that, in
the form of so-called "safe points".
E.g. most POSIX signal handlers just set some global var which is then
polled from the main thread.

Stefan

(FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
off-topic.)

On 2021-12-10 19:20, EricP wrote:
> Niklas Holsti wrote:
>> On 2021-12-09 19:28, EricP wrote:
>>> Niklas Holsti wrote:
>>>> On 2021-12-09 0:43, EricP wrote:
>>>>>
>>>>> What is lost here is that it takes an AST which acts like a thread
>>>>> interrupt and turns it into something that is delivered by polling.
>>>>
>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>> accept statement has a time-out so that the task can periodically or
>>>> sporadically do something else in between waiting.
>>>
>>> If either the entry or accept statement has a time-out I consider
>>> that a polling interface as it is checking for a condition then
>>> doing something else, pretty much the definition of busy-waiting.
>>
>>
>> Your definition of busy-waiting is strange. Suppose the accept has a
>> time-out of one second, because the task has to record a short status
>> message once per second, taking, say, 1 ms of processing time. Then,
>> if no-one calls the entry, the task is busy only 1 ms per second,
>> _and_ doing useful (required) work for that 1 ms.
>>
>> My definition of busy-waiting is waiting that consumes processor time
>> without doing any useful work during the wait, which is not the case
>> for accepts with time-outs.
>
> My definition is based on differences in cost and synchronization.
>
> The word poll means to collect a sample of values, usually opinions.

I was commenting on your definition of busy-waiting, not of polling.

I agree that a looped accept with a time-out has a polling aspect,
because the entry call will sometimes not be accepted immediately. But
it is not busy-waiting. And interrupts are often not accepted
immediately, either, sometimes because of interrupt-disabled regions,
and sometimes because of sequential processing of interrupts.

> For computer interfaces poll means repeatedly sampling the state of
> something to detect a change. [...]
>
> The alternative is interrupt semantics - being informed when a
> state actually has changed.

That is exactly what happens in an Ada accept statement - when the entry
is called, the accepting task is informed. Note that the accepting task
is the "interrupt handler"; the "interrupted task" is whatever task (if
any) is preempted by the accepting task when the call occurs.

On Friday, December 10, 2021 at 1:20:33 PM UTC-6, Niklas Holsti wrote:
> (FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
> off-topic.)
> On 2021-12-10 19:20, EricP wrote:
> > Niklas Holsti wrote:
> >> On 2021-12-09 19:28, EricP wrote:
> >>> Niklas Holsti wrote:
> >>>> On 2021-12-09 0:43, EricP wrote:
> >>>>>
> >>>>> What is lost here is that it takes an AST which acts like a thread
> >>>>> interrupt and turns it into something that is delivered by polling.
> >>>>
> >>>> A task waiting at an accept is not "polling", IMO, even if the
> >>>> accept statement has a time-out so that the task can periodically or
> >>>> sporadically do something else in between waiting.
> >>>
> >>> If either the entry or accept statement has a time-out I consider
> >>> that a polling interface as it is checking for a condition then
> >>> doing something else, pretty much the definition of busy-waiting.
> >>
> >>
> >> Your definition of busy-waiting is strange. Suppose the accept has a
> >> time-out of one second, because the task has to record a short status
> >> message once per second, taking, say, 1 ms of processing time. Then,
> >> if no-one calls the entry, the task is busy only 1 ms per second,
> >> _and_ doing useful (required) work for that 1 ms.
> >>
> >> My definition of busy-waiting is waiting that consumes processor time
> >> without doing any useful work during the wait, which is not the case
> >> for accepts with time-outs.
> >
> > My definition is based on differences in cost and synchronization.
> >
> > The word poll means to collect a sample of values, usually opinions.
> I was commenting on your definition of busy-waiting, not of polling.
>
> I agree that a looped accept with a time-out has a polling aspect,
> because the entry call will sometimes not be accepted immediately. But
> it is not busy-waiting. And interrupts are often not accepted
> immediately, either, sometimes because of interrupt-disabled regions,
> and sometimes because of sequential processing of interrupts.
> > For computer interfaces poll means repeatedly sampling the state of
> > something to detect a change. [...]
> >
> > The alternative is interrupt semantics - being informed when a
> > state actually has changed.
<
> That is exactly what happens in an Ada accept statement - when the entry
> is called, the accepting task is informed. Note that the accepting task
> is the "interrupt handler"; the "interrupted task" is whatever task (if
> any) is preempted by the accepting task when the call occurs.
<
In a multiprocessor with idle cores, nobody has to be preempted !!
<
However, the caller is placed in a wait state until the end of the rendezvous.
<
On the other hand, I do not see in the ADA specs that the acceptor gets
interrupted in any way. Consider a situation where multiple tasks can all
accept the same set of entry points. Which one receives the "interrupt" ?
If none of the acceptors gets around to accepting the call "for a while"
in what way does it smell like at least one of them were "interrupted" ?
<
So, the words "preempted" and "interrupt" are not workable.
<
No, trying to use old interrupt terminology in a new ADA rendezvous
environment is not going to fly.

MitchAlsup wrote:
> On Thursday, December 9, 2021 at 11:33:58 AM UTC-6, EricP wrote:
>> Niklas Holsti wrote:
>>> A task waiting at an accept is not "polling", IMO, even if the accept
>>> statement has a time-out so that the task can periodically or
>>> sporadically do something else in between waiting.
> <
>> If either the entry or accept statement has a time-out I consider
>> that a polling interface as it is checking for a condition then
>> doing something else, pretty much the definition of busy-waiting.
> <
> I don' know about that.
> <
> Consider a block of code with 3 accept entries and a delay.
> <
> Why is this not a 4 entry accept where the 4th entry is connected
> to a timer event not an accept event ?

If the delay == 0 then the tasks never wait, they just check
the state and return and that is polling.

If the delay != 0 then the tasks will will be asleep so not polling,
but when the timer times out the task wakes up and checks the state
and returns, so a delayed poll.

In Windows the rendezvous would be implemented something like:

- server acquires OS mutex guarding interface queues
- server accept checks for any client entry waiting in queue
and if none server requests OS timer wakeup
- server pushes itself onto server queue, releases mutex,
and waits for OS event flag or timer timeout
- on timeout server wakes up, acquires mutex, checks again for
waiting client entry, release mutex
- server rendezvous complete

By the way, the Win32 OS function SignalObjectAndWait implements the
exit sequence for the above when there is no client or server waiting
atomically as a single system call:
release mutex, optionally enqueue timer, waits for event or timer,
if event or timer goes off cancel wait for the other and wake up.

Stefan Monnier wrote:
>> The alternative is interrupt semantics - being informed when a
>> state actually has changed.
>
> Of course, interrupts are handled by having the CPU poll the interrupt
> line(s) every cycle or so ;-)

I am aware of the tenuousness of my argument :-)

(I'm just being flippant - its not really that tenuous because while the
cpu may be sampling an interrupt line at the start of every instruction,
it is only testing 1 bit and it is doing so is parallel with all other
decode functions, and the cpu only does extra work if that bit == 1.
So the overhead costs is essentially zero if there is no interrupt.)

>> Polling uses resources to continuously check for changes and increases
>> in cost as number of samples scales up, whereas interrupts do not.
>
> It's only that the polling done to handle interrupts is super cheap.

The distinction is not whether polling takes place or not as
some kinds of interrupts can require polling to determine a source.

An OR-gate tree is all that is required to determine that something
has happened someplace, but we may not know exactly where.

The distinction is that interrupts initiate further work only
when a state change is already _known_ to have occurred.

Client initiated polling expends work to determine whether a state
change has occurred and as such is always wasteful to some degree.

>> But interrupts having significant synchronization and race condition
>> issues that polling does not.
>
> Indeed. Software often implements a form of polling on top of that, in
> the form of so-called "safe points".
> E.g. most POSIX signal handlers just set some global var which is then
> polled from the main thread.
>
>
> Stefan

I prefer WinNT's structured exceptions so as to catch such "signals"
exactly where and when they occur.

On 2021-12-10 21:45, MitchAlsup wrote:
> On Friday, December 10, 2021 at 1:20:33 PM UTC-6, Niklas Holsti wrote:
>> (FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
>> off-topic.)
>> On 2021-12-10 19:20, EricP wrote:

[ snipping bits irrelevant to Mitch's post. ]

>>> For computer interfaces poll means repeatedly sampling the state of
>>> something to detect a change. [...]
>>>
>>> The alternative is interrupt semantics - being informed when a
>>> state actually has changed.
> <
>> That is exactly what happens in an Ada accept statement - when the entry
>> is called, the accepting task is informed. Note that the accepting task
>> is the "interrupt handler"; the "interrupted task" is whatever task (if
>> any) is preempted by the accepting task when the call occurs.
>
> In a multiprocessor with idle cores, nobody has to be preempted !!

Agreed (I said "if any").

> However, the caller is placed in a wait state until the end of the
> rendezvous.

Yes, but also in a "real" (HW) interrupt the interrupting device usually
cannot trigger a new interrupt until the interrupt handler somehow
re-enables or unmasks that device as an interrupt source. This is
analogous to suspending the calling task during an Ada rendez-vous.

Note that the accepting task can make the actual rendez-vous very brief;
for example, the accepting task can just copy the entry parameters for
later use and then end the rendez-vous (if that makes sense in the
application). The caller and acceptor can then proceed in parallel until
the next rendez-vous.

> On the other hand, I do not see in the ADA specs that the acceptor gets
> interrupted in any way.

As I said (quoted above), the acceptor is equivalent to an interrupt
*handler*. An interrupt handler does not get interrupted by the interrupt.

> Consider a situation where multiple tasks can all accept the same set
> of entry points. Which one receives the "interrupt" ?

That cannot happen in Ada, because entry points are identified by the
task instance in addition to the entry name. While there can be multiple
instances of a task, the caller must identify the instance that it
wishes to call (usually by a pointer to the task instance, if there are
several instances).

If you want to do some sort of "interrupt distribution" you can program
it, for example by keeping a queue of available acceptor task instances
and making the caller use the next instance from the queue.

> If none of the acceptors gets around to accepting the call "for a while"
> in what way does it smell like at least one of them were "interrupted" ?

Again, the acceptor is (analogous to) the interrupt *handler*, not to
the interrupted task.

An acceptor task not accepting a call for a while is analogous to the
interrupt being disabled or masked for a while.

> So, the words "preempted" and "interrupt" are not workable.
> <
> No, trying to use old interrupt terminology in a new ADA rendezvous
> environment is not going to fly.

I think you misunderstood the analogy.

On 2021-12-10 22:14, EricP wrote:
> MitchAlsup wrote:
>> On Thursday, December 9, 2021 at 11:33:58 AM UTC-6, EricP wrote:
>>> Niklas Holsti wrote:
>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>> accept statement has a time-out so that the task can periodically or
>>>> sporadically do something else in between waiting.

[snip]

> In Windows the rendezvous would be implemented something like:

In Ada terms, you are describing how an accept statement (with time-out)
can be implemented -- not how the rendez-vous itself is implemented. The
rendez-vous is what happens when the server executes the client's call.

> - server acquires OS mutex guarding interface queues
> - server accept checks for any client entry waiting in queue
>   and if none server requests OS timer wakeup
> - server pushes itself onto server queue, releases mutex,
>   and waits for OS event flag or timer timeout
> - on timeout server wakes up, acquires mutex, checks again for
>   waiting client entry, release mutex

No. Time-out means that there were and are no clients calling now, and
the server wants to do something else - cancelling the "accept".

At some later time, when the server has dealt with the time-out, it
returns to the accept-with-timeout and at _that_ point checks for
waiting client calls.

> - server rendezvous complete

(I forgot to make a point in my last post, apologies.)

On 2021-12-10 22:14, EricP wrote:
> MitchAlsup wrote:
>> On Thursday, December 9, 2021 at 11:33:58 AM UTC-6, EricP wrote:
>>> Niklas Holsti wrote:
>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>> accept statement has a time-out so that the task can periodically or
>>>> sporadically do something else in between waiting.
>> <
>>> If either the entry or accept statement has a time-out I consider
>>> that a polling interface as it is checking for a condition then doing
>>> something else, pretty much the definition of busy-waiting.
>> <
>> I don' know about that.
>> <
>> Consider a block of code with 3 accept entries and a delay.
>> <
>> Why is this not a 4 entry accept where the 4th entry is connected
>> to a timer event not an accept event ?
>
> If the delay == 0 then the tasks never wait, they just check
> the state and return and that is polling.

Agreed, but not really what is being discussed.

> If the delay != 0 then the tasks will will be asleep so not polling,

BUT the task will be woken up if a client calls it, even before the
expiration of the time-out delay.

On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
> On 2021-12-10 21:45, MitchAlsup wrote:
> > On Friday, December 10, 2021 at 1:20:33 PM UTC-6, Niklas Holsti wrote:
> >> (FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
> >> off-topic.)
> >> On 2021-12-10 19:20, EricP wrote:
> [ snipping bits irrelevant to Mitch's post. ]
> >>> For computer interfaces poll means repeatedly sampling the state of
> >>> something to detect a change. [...]
> >>>
> >>> The alternative is interrupt semantics - being informed when a
> >>> state actually has changed.
> > <
> >> That is exactly what happens in an Ada accept statement - when the entry
> >> is called, the accepting task is informed. Note that the accepting task
> >> is the "interrupt handler"; the "interrupted task" is whatever task (if
> >> any) is preempted by the accepting task when the call occurs.
> >
> > In a multiprocessor with idle cores, nobody has to be preempted !!
> Agreed (I said "if any").
> > However, the caller is placed in a wait state until the end of the
> > rendezvous.
<
> Yes, but also in a "real" (HW) interrupt the interrupting device usually
> cannot trigger a new interrupt until the interrupt handler somehow
> re-enables or unmasks that device as an interrupt source.
<
{Being a HW guy} I was under the impression that the HW device could
send another interrupt and that it was the core receiving the interrupt
that turns off listening until the ISR gets to a certain point. You statement
above has the "who is doing what" backward.
<
But the above gets back to the point I was making a dozen entries above::
Interrupts are associated with threads {not directed "at" cores}
<
> This is
> analogous to suspending the calling task during an Ada rendez-vous.
<
Nothing is preventing the device from continuing to assert his interrupt wire;
what is happening is the interrupted core is no longer listening. This is
what gets negotiated (away) while the core is not-listening to the interrupt.
>
> Note that the accepting task can make the actual rendez-vous very brief;
> for example, the accepting task can just copy the entry parameters for
> later use and then end the rendez-vous (if that makes sense in the
> application). The caller and acceptor can then proceed in parallel until
> the next rendez-vous.
<
> > On the other hand, I do not see in the ADA specs that the acceptor gets
> > interrupted in any way.
<
> As I said (quoted above), the acceptor is equivalent to an interrupt
> *handler*. An interrupt handler does not get interrupted by the interrupt.
<
No, the handler receives control after said interrupt "transpires".
<
> > Consider a situation where multiple tasks can all accept the same set
> > of entry points. Which one receives the "interrupt" ?
<
> That cannot happen in Ada, because entry points are identified by the
> task instance in addition to the entry name. While there can be multiple
> instances of a task, the caller must identify the instance that it
> wishes to call (usually by a pointer to the task instance, if there are
> several instances).
<
So, how does one setup the scenario in ADA where a varying number of
service providers handle service requests based on the service load being
applied ? For example: in the Linux world every running thread can ask
for a SATA disk read. And because the OS-service handler runs "on top of"
the requesting thread, all such threads proceed concurrently.
<
I was under the impression that one could spawn as many service providers
as needed by spawning more tasks has handlers.
>
> If you want to do some sort of "interrupt distribution" you can program
> it, for example by keeping a queue of available acceptor task instances
> and making the caller use the next instance from the queue.
<
What I was looking for is accept distribution. Thread[k] can call the "read"
accept point and this can be accepted by any of as many accept "read"
threads as are potentially running.
<
> > If none of the acceptors gets around to accepting the call "for a while"
> > in what way does it smell like at least one of them were "interrupted" ?
<
> Again, the acceptor is (analogous to) the interrupt *handler*, not to
> the interrupted task.
>
> An acceptor task not accepting a call for a while is analogous to the
> interrupt being disabled or masked for a while.
<
Minus stuff like timeouts, and buffer overruns.
<
> > So, the words "preempted" and "interrupt" are not workable.
> > <
> > No, trying to use old interrupt terminology in a new ADA rendezvous
> > environment is not going to fly.
<
> I think you misunderstood the analogy.
<
Playing the role of Captain Obvious again ?

On 2021-12-10 23:27, MitchAlsup wrote:
> On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
>> On 2021-12-10 21:45, MitchAlsup wrote:
>>> On Friday, December 10, 2021 at 1:20:33 PM UTC-6, Niklas Holsti wrote:
>>>> (FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
>>>> off-topic.)
>>>> On 2021-12-10 19:20, EricP wrote:
>> [ snipping bits irrelevant to Mitch's post. ]
>>>>> For computer interfaces poll means repeatedly sampling the state of
>>>>> something to detect a change. [...]
>>>>>
>>>>> The alternative is interrupt semantics - being informed when a
>>>>> state actually has changed.
>>> <
>>>> That is exactly what happens in an Ada accept statement - when the entry
>>>> is called, the accepting task is informed. Note that the accepting task
>>>> is the "interrupt handler"; the "interrupted task" is whatever task (if
>>>> any) is preempted by the accepting task when the call occurs.
>>>
>>> In a multiprocessor with idle cores, nobody has to be preempted !!
>> Agreed (I said "if any").
>>> However, the caller is placed in a wait state until the end of the
>>> rendezvous.
> <
>> Yes, but also in a "real" (HW) interrupt the interrupting device usually
>> cannot trigger a new interrupt until the interrupt handler somehow
>> re-enables or unmasks that device as an interrupt source.
> <
> {Being a HW guy} I was under the impression that the HW device could
> send another interrupt and that it was the core receiving the interrupt
> that turns off listening until the ISR gets to a certain point. You statement
> above has the "who is doing what" backward.

Analogies only stretch so far... you are right that some HW devices can
signal interrupts at any time, but I think I'm right that the core/SW
usually does not react to the new interrupt signal until it is ready to
do so, that is, until it can "accept" the interrupt ;-)

>>> On the other hand, I do not see in the ADA specs that the acceptor gets
>>> interrupted in any way.
> <
>> As I said (quoted above), the acceptor is equivalent to an interrupt
>> *handler*. An interrupt handler does not get interrupted by the interrupt.
> <
> No, the handler receives control after said interrupt "transpires".

Yes, exactly like an Ada acceptor task receives control after the
client's entry call is accepted. It is not interrupted by the call.

>>> Consider a situation where multiple tasks can all accept the same set
>>> of entry points. Which one receives the "interrupt" ?
> <
>> That cannot happen in Ada, because entry points are identified by the
>> task instance in addition to the entry name. While there can be multiple
>> instances of a task, the caller must identify the instance that it
>> wishes to call (usually by a pointer to the task instance, if there are
>> several instances).
> <
> So, how does one setup the scenario in ADA where a varying number of
> service providers handle service requests based on the service load being
> applied ? For example: in the Linux world every running thread can ask
> for a SATA disk read. And because the OS-service handler runs "on top of"
> the requesting thread, all such threads proceed concurrently.
> <
> I was under the impression that one could spawn as many service providers
> as needed by spawning more tasks has handlers.

Such things can be programmed, but are not provided as a built-in Ada
feature.

>> If you want to do some sort of "interrupt distribution" you can program
>> it, for example by keeping a queue of available acceptor task instances
>> and making the caller use the next instance from the queue.
> <
> What I was looking for is accept distribution. Thread[k] can call the "read"
> accept point and this can be accepted by any of as many accept "read"
> threads as are potentially running.

That is not provided as primitive in Ada, but can be programmed, of
course. For example, the primary rendez-vous code can "requeue" the call
to another entry, of some task or some protected object, and that task
or protected object can be selected from a pool of secondary "servers"
in any way you want. The requeue statement completes the primary
rendez-vous. The caller is still suspended on the requeued call, but the
primary server is released to continue its work, usually by accepting
the next call.

>>> If none of the acceptors gets around to accepting the call "for a while"
>>> in what way does it smell like at least one of them were "interrupted" ?
> <
>> Again, the acceptor is (analogous to) the interrupt *handler*, not to
>> the interrupted task.
>>
>> An acceptor task not accepting a call for a while is analogous to the
>> interrupt being disabled or masked for a while.
> <
> Minus stuff like timeouts, and buffer overruns.

A time-out alternative for an accept statement does not prevent a client
call from being accepted before the time-out expires.

>>> So, the words "preempted" and "interrupt" are not workable.
>>> <
>>> No, trying to use old interrupt terminology in a new ADA rendezvous
>>> environment is not going to fly.
> <
>> I think you misunderstood the analogy.
> <
> Playing the role of Captain Obvious again ?

Please clarify that remark. If it was just an insult, don't bother :-|

Niklas Holsti wrote:
> On 2021-12-10 22:14, EricP wrote:
>> MitchAlsup wrote:
>>> On Thursday, December 9, 2021 at 11:33:58 AM UTC-6, EricP wrote:
>>>> Niklas Holsti wrote:
>>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>>> accept statement has a time-out so that the task can periodically
>>>>> or sporadically do something else in between waiting.
>
>
> [snip]
>
>
>> In Windows the rendezvous would be implemented something like:
>
>
> In Ada terms, you are describing how an accept statement (with time-out)
> can be implemented -- not how the rendez-vous itself is implemented. The
> rendez-vous is what happens when the server executes the client's call.

Ok

>> - server acquires OS mutex guarding interface queues
>> - server accept checks for any client entry waiting in queue
>> and if none server requests OS timer wakeup
>> - server pushes itself onto server queue, releases mutex,
>> and waits for OS event flag or timer timeout
>> - on timeout server wakes up, acquires mutex, checks again for
>> waiting client entry, release mutex
>
>
> No. Time-out means that there were and are no clients calling now, and
> the server wants to do something else - cancelling the "accept".

I know. That last step is covering how it cancels the accept.
It deals with possible race condition of an accept timer going off and
just then a client arrives at an entry and grabs the guarding mutex
before the server can actually remove itself from the accept queue
and the client selects that server and tries to wake it up.

So when the server finally gets the mutex it finds that it
now has a client entry to accept instead.
However if there is no client then it pops itself from the accept queue,
releases the mutex, and executes its delayed statements.

> At some later time, when the server has dealt with the time-out, it
> returns to the accept-with-timeout and at _that_ point checks for
> waiting client calls.

Yes.

On Friday, December 10, 2021 at 4:16:00 PM UTC-6, Niklas Holsti wrote:
> On 2021-12-10 23:27, MitchAlsup wrote:

> >>
> >> An acceptor task not accepting a call for a while is analogous to the
> >> interrupt being disabled or masked for a while.
> > <
> > Minus stuff like timeouts, and buffer overruns.
<
Hardware timeouts and HW buffer overruns because ISR SW was not "quick"
enough.
<
> A time-out alternative for an accept statement does not prevent a client
> call from being accepted before the time-out expires.
<
Not the accept or delay that ADA has--the contrapositive of what ADA is doing.
HW needing to raise another interrupt because the first was not serviced in
judicious time.
<
> >>> So, the words "preempted" and "interrupt" are not workable.
> >>> <
> >>> No, trying to use old interrupt terminology in a new ADA rendezvous
> >>> environment is not going to fly.
> > <
> >> I think you misunderstood the analogy.
> > <
> > Playing the role of Captain Obvious again ?
<
> Please clarify that remark. If it was just an insult, don't bother :-|
<
It was painfully obvious that I did not get the original analogy to anyone bothering
to read the thread. No insult implied, praise that you got my not getting it.

Niklas Holsti wrote:
> (FYI : still discussing Ada rendez-vous / polling / busy-waiting, still
> off-topic.)
>
> On 2021-12-10 19:20, EricP wrote:
>> Niklas Holsti wrote:
>>> On 2021-12-09 19:28, EricP wrote:
>>>> Niklas Holsti wrote:
>>>>> On 2021-12-09 0:43, EricP wrote:
>>>>>>
>>>>>> What is lost here is that it takes an AST which acts like a thread
>>>>>> interrupt and turns it into something that is delivered by polling.
>>>>>
>>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>>> accept statement has a time-out so that the task can periodically
>>>>> or sporadically do something else in between waiting.
>>>>
>>>> If either the entry or accept statement has a time-out I consider
>>>> that a polling interface as it is checking for a condition then
>>>> doing something else, pretty much the definition of busy-waiting.
>>>
>>>
>>> Your definition of busy-waiting is strange. Suppose the accept has a
>>> time-out of one second, because the task has to record a short status
>>> message once per second, taking, say, 1 ms of processing time. Then,
>>> if no-one calls the entry, the task is busy only 1 ms per second,
>>> _and_ doing useful (required) work for that 1 ms.
>>>
>>> My definition of busy-waiting is waiting that consumes processor time
>>> without doing any useful work during the wait, which is not the case
>>> for accepts with time-outs.
>>
>> My definition is based on differences in cost and synchronization.
>>
>> The word poll means to collect a sample of values, usually opinions.
>
>
> I was commenting on your definition of busy-waiting, not of polling.

Ok, I see your point. I was thinking of keeping busy while you wait.
I usually use the term spin-wait to imply nothing happens.

> I agree that a looped accept with a time-out has a polling aspect,
> because the entry call will sometimes not be accepted immediately. But
> it is not busy-waiting. And interrupts are often not accepted
> immediately, either, sometimes because of interrupt-disabled regions,
> and sometimes because of sequential processing of interrupts.

Disabled interrupts is a different topic, related to reentrancy
and managing access to OS data structures.

>> For computer interfaces poll means repeatedly sampling the state of
>> something to detect a change. [...]
>>
>> The alternative is interrupt semantics - being informed when a
>> state actually has changed.
>
>
> That is exactly what happens in an Ada accept statement - when the entry
> is called, the accepting task is informed. Note that the accepting task
> is the "interrupt handler"; the "interrupted task" is whatever task (if
> any) is preempted by the accepting task when the call occurs.

I don't think interrupt is a good analogy to what a rendezvous does.
It is really quite a complex atomic operation.

Select statements with multiple OR options, possibly with guards,
allow entrys and accepts to atomically wait in multiple queues at once,
with multiple possible timers.
When a client entry matches a server accept they bind and dequeue
all other options and timers atomically at once.

A critical section around a struct that contains queues for each
entry and accept option, with event flags to wake up waiters
is how I think it is best described.

On 12/10/2021 2:15 PM, Niklas Holsti wrote:
> On 2021-12-10 23:27, MitchAlsup wrote:
>> On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
>>> On 2021-12-10 21:45, MitchAlsup wrote:

snip

>> What I was looking for is accept distribution. Thread[k] can call the
>> "read"
>> accept point and this can be accepted by any of as many accept "read"
>> threads as are potentially running.
>
>
> That is not provided as primitive in Ada, but can be programmed, of
> course. For example, the primary rendez-vous code can "requeue" the call
> to another entry, of some task or some protected object, and that task
> or protected object can be selected from a pool of secondary "servers"
> in any way you want. The requeue statement completes the primary
> rendez-vous. The caller is still suspended on the requeued call, but the
> primary server is released to continue its work, usually by accepting
> the next call.

But do you have to program all of this "requeueing" yourself? And in
particular, do you have to set up locks for the queues, request
exclusive access to them, etc.? This is just the kind of thing that the
hardware assisted message passing was designed to eliminate. :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 2021-12-11 0:46, MitchAlsup wrote:
> On Friday, December 10, 2021 at 4:16:00 PM UTC-6, Niklas Holsti wrote:

>> Please clarify that remark. If it was just an insult, don't bother :-|

Mitch:

> It was painfully obvious that I did not get the original analogy to anyone bothering
> to read the thread. No insult implied, praise that you got my not getting it.

Ok, thanks. I didn't understand that you understood that you had
misunderstood :-)

On 2021-12-11 4:08, EricP wrote:
> Niklas Holsti wrote:
>> (FYI : still discussing Ada rendez-vous / polling / busy-waiting,
>> still off-topic.)
>>
>> On 2021-12-10 19:20, EricP wrote:
>>> Niklas Holsti wrote:
>>>> On 2021-12-09 19:28, EricP wrote:
>>>>> Niklas Holsti wrote:
>>>>>> On 2021-12-09 0:43, EricP wrote:
>>>>>>>
>>>>>>> What is lost here is that it takes an AST which acts like a thread
>>>>>>> interrupt and turns it into something that is delivered by polling.
>>>>>>
>>>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>>>> accept statement has a time-out so that the task can periodically
>>>>>> or sporadically do something else in between waiting.
>>>>>
>>>>> If either the entry or accept statement has a time-out I consider
>>>>> that a polling interface as it is checking for a condition then
>>>>> doing something else, pretty much the definition of busy-waiting.
>>>>
>>>>
>>>> Your definition of busy-waiting is strange. Suppose the accept has a
>>>> time-out of one second, because the task has to record a short
>>>> status message once per second, taking, say, 1 ms of processing
>>>> time. Then, if no-one calls the entry, the task is busy only 1 ms
>>>> per second, _and_ doing useful (required) work for that 1 ms.
>>>>
>>>> My definition of busy-waiting is waiting that consumes processor
>>>> time without doing any useful work during the wait, which is not the
>>>> case for accepts with time-outs.

[snip]

> Ok, I see your point. I was thinking of keeping busy while you wait.
> I usually use the term spin-wait to imply nothing happens.

I see. I tend to think of busy-wait and spin-wait as synonyms, as in
Wikipedia (https://en.wikipedia.org/wiki/Busy_waiting).

>> I agree that a looped accept with a time-out has a polling aspect,
>> because the entry call will sometimes not be accepted immediately. But
>> it is not busy-waiting. And interrupts are often not accepted
>> immediately, either, sometimes because of interrupt-disabled regions,
>> and sometimes because of sequential processing of interrupts.
>
> Disabled interrupts is a different topic, related to reentrancy
> and managing access to OS data structures.

If an Ada run-time system maps interrupts to calls of task entries or
protected operations, the topics are intertwined. For example, in an Ada
bare-HW system on SPARC, with protected objects using priority ceilings
for mutual exclusion, when an interrupt is handled by a protected-object
operation the call runs at the interrupt priority, effectively masking
further interrupts at that (or lower) priorities. And all other calls to
that same protected object (say, from other tasks) also run at the
interrupt priority, with the same effect.

>>> For computer interfaces poll means repeatedly sampling the state of
>>> something to detect a change. [...]
>>>
>>> The alternative is interrupt semantics - being informed when a
>>> state actually has changed.
>>
>>
>> That is exactly what happens in an Ada accept statement - when the
>> entry is called, the accepting task is informed. Note that the
>> accepting task is the "interrupt handler"; the "interrupted task" is
>> whatever task (if any) is preempted by the accepting task when the
>> call occurs.
>
> I don't think interrupt is a good analogy to what a rendezvous does.
> It is really quite a complex atomic operation.

Sure, it is complex to implement, but semantically its purpose is more
like an interrupt (handler) than like polling. But it can be used to
implement polling, as already discussed.

> Select statements with multiple OR options, possibly with guards,
> allow entrys and accepts to atomically wait in multiple queues at once,
> with multiple possible timers.
> When a client entry matches a server accept they bind and dequeue
> all other options and timers atomically at once.

Only the timers are dequeued (cancelled). The other (non-selected) calls
remain pending while the selected client call is executed in a
rendez-vous, and then also until the next execution of the select statement.

> A critical section around a struct that contains queues for each
> entry and accept option, with event flags to wake up waiters
> is how I think it is best described.

Something like that is the usual implementation, yes. In Ada systems
using a limited tasking system (say, the "Ravenscar profile") the
implementation can be simpler.

On 2021-12-11 7:56, Stephen Fuld wrote:
> On 12/10/2021 2:15 PM, Niklas Holsti wrote:
>> On 2021-12-10 23:27, MitchAlsup wrote:
>>> On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
>>>> On 2021-12-10 21:45, MitchAlsup wrote:
>
> snip
>
>
>>> What I was looking for is accept distribution. Thread[k] can call
>>> the "read" accept point and this can be accepted by any of as
>>> many accept "read" threads as are potentially running.
>>
>>
>> That is not provided as primitive in Ada, but can be programmed, of
>> course. For example, the primary rendez-vous code can "requeue" the
>> call to another entry, of some task or some protected object, and that
>> task or protected object can be selected from a pool of secondary
>> "servers" in any way you want. The requeue statement completes the
>> primary rendez-vous. The caller is still suspended on the requeued
>> call, but the primary server is released to continue its work, usually
>> by accepting the next call.
>
> But do you have to program all of this "requeueing" yourself?

You do have to program the "requeue" statements, yes, and the logic to
select the target of the requeue (the "secondary server").

> And in particular, do you have to set up locks for the queues,
> request exclusive access to them, etc.?

Mainly no; the Ada run-time system handles the queueing of entry calls
to entries, as well as the exlusive access or other protections
intrinsic to Ada tasks and Ada protected objects. Of course that can
need a significant amount of code in the run-time system.

> This is just the kind of thing that the hardware assisted message
> passing was designed to eliminate. :-(

So perhaps this sub-thread is not much off-topic after all.

It would be very good, of course, if some of this complexity could be
implemented in the HW. However, in the past there were some efforts to
implement HW co-processors to handle Ada tasking operations, such as
maintaining the set of runnable tasks, implementing timers, etc., but
(just as for language-specific processors) it turned out that the speed
of SW in general-purpose processors increased so quickly that the
special-purpose HW was soon left behind.

Then again, if today the single-thread speed of processors is no longer
increasing much, HW support today could be more successful and
longer-lasting. The obvious question is how much of this complex job can
be cast into HW without losing the flexibility that is needed to support
various programming languages, programming styles, and applications.

On 12/11/2021 3:32 AM, Niklas Holsti wrote:
> On 2021-12-11 7:56, Stephen Fuld wrote:
>> On 12/10/2021 2:15 PM, Niklas Holsti wrote:
>>> On 2021-12-10 23:27, MitchAlsup wrote:
>>>> On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
>>>>> On 2021-12-10 21:45, MitchAlsup wrote:
>>
>> snip
>>
>>
>>>> What I was looking for is accept distribution. Thread[k] can call
>>>> the "read" accept point and this can be accepted by any of as
>>>> many accept "read" threads as are potentially running.
>>>
>>>
>>> That is not provided as primitive in Ada, but can be programmed, of
>>> course. For example, the primary rendez-vous code can "requeue" the
>>> call to another entry, of some task or some protected object, and
>>> that task or protected object can be selected from a pool of
>>> secondary "servers" in any way you want. The requeue statement
>>> completes the primary rendez-vous. The caller is still suspended on
>>> the requeued call, but the primary server is released to continue its
>>> work, usually by accepting the next call.
>>
>> But do you have to program all of this "requeueing" yourself?
>
>
> You do have to program the "requeue" statements, yes, and the logic to
> select the target of the requeue (the "secondary server").
>
>
>> And in particular, do you have to set up locks for the queues,
>> request exclusive access to them, etc.?
>
> Mainly no; the Ada run-time system handles the queueing of entry calls
> to entries, as well as the exlusive access or other protections
> intrinsic to Ada tasks and Ada protected objects. Of course that can
> need a significant amount of code in the run-time system.
>
>
>> This is just the kind of thing that the hardware assisted message
>> passing was designed to eliminate.  :-(
>
> So perhaps this sub-thread is not much off-topic after all.

I was too quick in my reply. I shouldn't have said "hardware assisted"
above. It is really message passing that is designed to eliminate the
need to program the queues, etc. The hardware assist just makes it more
efficient.

From my interpretation of your description, in the current Ada system,
it seems to require shared memory between the "sender", and all of the
"receivers", as they must access the common queues, etc. Is that true?
If so, then a message passing based system could help, as it could
eliminate that requirement, allowing much more flexibility in allocating
processes to different processors not sharing memory with the "sending"
process.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Niklas Holsti wrote:
> On 2021-12-11 4:08, EricP wrote:
>> Niklas Holsti wrote:
>>> (FYI : still discussing Ada rendez-vous / polling / busy-waiting,
>>> still off-topic.)
>>>
>>> On 2021-12-10 19:20, EricP wrote:
>>>> Niklas Holsti wrote:
>>>>> On 2021-12-09 19:28, EricP wrote:
>>>>>> Niklas Holsti wrote:
>>>>>>> On 2021-12-09 0:43, EricP wrote:
>>>>>>>>
>>>>>>>> What is lost here is that it takes an AST which acts like a thread
>>>>>>>> interrupt and turns it into something that is delivered by polling.
>>>>>>>
>>>>>>> A task waiting at an accept is not "polling", IMO, even if the
>>>>>>> accept statement has a time-out so that the task can periodically
>>>>>>> or sporadically do something else in between waiting.
>>>>>>
>>>>>> If either the entry or accept statement has a time-out I consider
>>>>>> that a polling interface as it is checking for a condition then
>>>>>> doing something else, pretty much the definition of busy-waiting.
>>>>>
>>>>>
>>>>> Your definition of busy-waiting is strange. Suppose the accept has
>>>>> a time-out of one second, because the task has to record a short
>>>>> status message once per second, taking, say, 1 ms of processing
>>>>> time. Then, if no-one calls the entry, the task is busy only 1 ms
>>>>> per second, _and_ doing useful (required) work for that 1 ms.
>>>>>
>>>>> My definition of busy-waiting is waiting that consumes processor
>>>>> time without doing any useful work during the wait, which is not
>>>>> the case for accepts with time-outs.
>
> [snip]
>
>> Ok, I see your point. I was thinking of keeping busy while you wait.
>> I usually use the term spin-wait to imply nothing happens.
>
>
> I see. I tend to think of busy-wait and spin-wait as synonyms, as in
> Wikipedia (https://en.wikipedia.org/wiki/Busy_waiting).

I bow to the authority of Wikipedia.
I guess I'll need a new name for actually working while spin-waiting.

>>> I agree that a looped accept with a time-out has a polling aspect,
>>> because the entry call will sometimes not be accepted immediately.
>>> But it is not busy-waiting. And interrupts are often not accepted
>>> immediately, either, sometimes because of interrupt-disabled regions,
>>> and sometimes because of sequential processing of interrupts.
>>
>> Disabled interrupts is a different topic, related to reentrancy
>> and managing access to OS data structures.
>
>
> If an Ada run-time system maps interrupts to calls of task entries or
> protected operations, the topics are intertwined. For example, in an Ada
> bare-HW system on SPARC, with protected objects using priority ceilings
> for mutual exclusion, when an interrupt is handled by a protected-object
> operation the call runs at the interrupt priority, effectively masking
> further interrupts at that (or lower) priorities. And all other calls to
> that same protected object (say, from other tasks) also run at the
> interrupt priority, with the same effect.

Yes, that is the way many OS's do it too but with cpu spinlocks.
Those interrupt priority spinlocks only guard the specific object
accessed by that interrupt handler, and other OS data structures
must not be accessed while at interrupt level.

The bulk of the non-reentrant OS like the thread scheduler runs at a
software pseudo-interrupt priority above threads and below HW interrupts.

>>>> For computer interfaces poll means repeatedly sampling the state of
>>>> something to detect a change. [...]
>>>>
>>>> The alternative is interrupt semantics - being informed when a
>>>> state actually has changed.
>>>
>>>
>>> That is exactly what happens in an Ada accept statement - when the
>>> entry is called, the accepting task is informed. Note that the
>>> accepting task is the "interrupt handler"; the "interrupted task" is
>>> whatever task (if any) is preempted by the accepting task when the
>>> call occurs.
>>
>> I don't think interrupt is a good analogy to what a rendezvous does.
>> It is really quite a complex atomic operation.
>
>
> Sure, it is complex to implement, but semantically its purpose is more
> like an interrupt (handler) than like polling. But it can be used to
> implement polling, as already discussed.
>
>
>> Select statements with multiple OR options, possibly with guards,
>> allow entrys and accepts to atomically wait in multiple queues at once,
>> with multiple possible timers.
>> When a client entry matches a server accept they bind and dequeue
>> all other options and timers atomically at once.
>
>
> Only the timers are dequeued (cancelled). The other (non-selected) calls
> remain pending while the selected client call is executed in a
> rendez-vous, and then also until the next execution of the select
> statement.

Yes. sorry, that was me misremembering how an entry select statement works.

I remembered that Ada accept statement could have a select statement
to allow multiple accept alternatives at once.

select
accept A (...);
or
accept B (...);
end select;

I had, mistakenly, thought that an entry select statement also allowed
multiple entry options to select different servers based on which accept
is available first. Something like:

entry A (...);
entry B (...);
entry C (...);

select
A (...);
or
B (...);
or
C (...);
or
delay 123.4;
end select;

But looking at the Ada LRM I see that it does _not_ allow multiple
entry choices, just a delay or an ELSE option.

On Saturday, December 11, 2021 at 10:38:03 AM UTC-6, Stephen Fuld wrote:
> On 12/11/2021 3:32 AM, Niklas Holsti wrote:
> > On 2021-12-11 7:56, Stephen Fuld wrote:
> >> On 12/10/2021 2:15 PM, Niklas Holsti wrote:
> >>> On 2021-12-10 23:27, MitchAlsup wrote:
> >>>> On Friday, December 10, 2021 at 2:34:20 PM UTC-6, Niklas Holsti wrote:
> >>>>> On 2021-12-10 21:45, MitchAlsup wrote:
> >>
> >> snip
> >>
> >>
> >>>> What I was looking for is accept distribution. Thread[k] can call
> >>>> the "read" accept point and this can be accepted by any of as
> >>>> many accept "read" threads as are potentially running.
> >>>
> >>>
> >>> That is not provided as primitive in Ada, but can be programmed, of
> >>> course. For example, the primary rendez-vous code can "requeue" the
> >>> call to another entry, of some task or some protected object, and
> >>> that task or protected object can be selected from a pool of
> >>> secondary "servers" in any way you want. The requeue statement
> >>> completes the primary rendez-vous. The caller is still suspended on
> >>> the requeued call, but the primary server is released to continue its
> >>> work, usually by accepting the next call.
> >>
> >> But do you have to program all of this "requeueing" yourself?
> >
> >
> > You do have to program the "requeue" statements, yes, and the logic to
> > select the target of the requeue (the "secondary server").
> >
> >
> >> And in particular, do you have to set up locks for the queues,
> >> request exclusive access to them, etc.?
> >
> > Mainly no; the Ada run-time system handles the queueing of entry calls
> > to entries, as well as the exlusive access or other protections
> > intrinsic to Ada tasks and Ada protected objects. Of course that can
> > need a significant amount of code in the run-time system.
> >
> >
> >> This is just the kind of thing that the hardware assisted message
> >> passing was designed to eliminate. :-(
> >
> > So perhaps this sub-thread is not much off-topic after all.
> I was too quick in my reply. I shouldn't have said "hardware assisted"
> above. It is really message passing that is designed to eliminate the
> need to program the queues, etc. The hardware assist just makes it more
> efficient.
>
> From my interpretation of your description, in the current Ada system,
> it seems to require shared memory between the "sender", and all of the
> "receivers", as they must access the common queues, etc. Is that true?
<
I can envision a system where one-guy owns and controls the queues
and has the ability to send messages to <basically> wake up various
threads.
<
I can envision that these woken up threads take a look at their CPU-affinity-set
and decide whether and who to context switch.
<
I further envision that this one-guy is NOT a CPU and is not running "instructions"
but just queueing commands.
<
> If so, then a message passing based system could help, as it could
> eliminate that requirement, allowing much more flexibility in allocating
> processes to different processors not sharing memory with the "sending"
> process.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)