Date: Sat, 9 May 2020 11:11:28 -0400
On Sat, May 9, 2020 at 10:53 Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Sat, May 9, 2020 at 10:18 AM connor horman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sat, May 9, 2020 at 10:14 Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> There is sigwait for this kind of use cases. Or any other kind of
>>> blocking - sleep, select, condition_variable::wait, etc.
>>>
>>> Busy waiting as a means of blocking the thread for extended periods of
>>> time is not something that should be encouraged, IMHO.
>>
>> Ah yes, that works quite well in embedded/freestanding (or os dev,
>> especially) where I don't have:
>> a) posix
>> b) <thread>
>> c) <mutex>
>> d) Stuff along those lines.
>>
>
> Well, that's the thing, right? All of what you just named are *libraries*,
> which are just collections of useful functions. You may not have access to
> those specific libraries, but you are certainly using a programming
> language (C++) that permits you to create functions of your own and place
> them into libraries.
>
> Rather than open-code an "infinite loop" (which would violate the
> compiler's assumption that all loops eventually terminate), it would be
> better for you to create a named function with the semantics you really
> intend:
> - spin the current thread forever without yielding
> - repeatedly yield and reschedule the current thread forever
> - deschedule the current thread so that it never gets scheduled again
> - deschedule the current thread until a signal is received (`sigwait`)
> etc.
> You have the tools to create a function with any of those semantics, for
> your platform of choice, and then you can call it from C++.
> The consensus in this (email ;)) thread seems to be that you should aim
> for the third or fourth semantics: busy-waiting is never a good idea, so
> you should look for a way to deschedule the current thread or task entirely.
>
As mentioned, there may not be such a functionality available. Descheduling
is a property of a hosted environment. C++ supports both hosted
environments (with a backing operating system) and freestanding
environments (without). How can I deschedule a function that is executing
until something interrupts it. I have nothing lower than the main thread in
this case. The only thing I can do is for(;;); while waiting for something
interesting to happen on my NMI or IRQ handlers (which then returns back to
the for(;;);) or STP which means that neither my NMI nor IRQ handlers will
actually get called, and I can't refresh the screen at the next Vertical
Blank (STP disables the system clock, period, until RESET). WAI may work on
the 65816, but IIRC its a 65816 "new" instruction, meaning its not
available on the 6502, and I don't know of anything similar for z80.
Again, looping is a high level concept, and it shouldn't be necessary to
write assembly code to do something as trivial as spin forever. I reserve
assembly for doing processor specific stuff like wrmsr on x86_64, or
setting up to jump into high level code (this is common regardless of
high-level language I choose).
>From a abstract perspective, having this violates the theorem that it is
unsolvable whether or not a program run in a UTM (which I do believe the
C++ abstract machine is supposed to be/emulate) will halt.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On Sat, May 9, 2020 at 10:18 AM connor horman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sat, May 9, 2020 at 10:14 Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> There is sigwait for this kind of use cases. Or any other kind of
>>> blocking - sleep, select, condition_variable::wait, etc.
>>>
>>> Busy waiting as a means of blocking the thread for extended periods of
>>> time is not something that should be encouraged, IMHO.
>>
>> Ah yes, that works quite well in embedded/freestanding (or os dev,
>> especially) where I don't have:
>> a) posix
>> b) <thread>
>> c) <mutex>
>> d) Stuff along those lines.
>>
>
> Well, that's the thing, right? All of what you just named are *libraries*,
> which are just collections of useful functions. You may not have access to
> those specific libraries, but you are certainly using a programming
> language (C++) that permits you to create functions of your own and place
> them into libraries.
>
> Rather than open-code an "infinite loop" (which would violate the
> compiler's assumption that all loops eventually terminate), it would be
> better for you to create a named function with the semantics you really
> intend:
> - spin the current thread forever without yielding
> - repeatedly yield and reschedule the current thread forever
> - deschedule the current thread so that it never gets scheduled again
> - deschedule the current thread until a signal is received (`sigwait`)
> etc.
> You have the tools to create a function with any of those semantics, for
> your platform of choice, and then you can call it from C++.
> The consensus in this (email ;)) thread seems to be that you should aim
> for the third or fourth semantics: busy-waiting is never a good idea, so
> you should look for a way to deschedule the current thread or task entirely.
>
As mentioned, there may not be such a functionality available. Descheduling
is a property of a hosted environment. C++ supports both hosted
environments (with a backing operating system) and freestanding
environments (without). How can I deschedule a function that is executing
until something interrupts it. I have nothing lower than the main thread in
this case. The only thing I can do is for(;;); while waiting for something
interesting to happen on my NMI or IRQ handlers (which then returns back to
the for(;;);) or STP which means that neither my NMI nor IRQ handlers will
actually get called, and I can't refresh the screen at the next Vertical
Blank (STP disables the system clock, period, until RESET). WAI may work on
the 65816, but IIRC its a 65816 "new" instruction, meaning its not
available on the 6502, and I don't know of anything similar for z80.
Again, looping is a high level concept, and it shouldn't be necessary to
write assembly code to do something as trivial as spin forever. I reserve
assembly for doing processor specific stuff like wrmsr on x86_64, or
setting up to jump into high level code (this is common regardless of
high-level language I choose).
>From a abstract perspective, having this violates the theorem that it is
unsolvable whether or not a program run in a UTM (which I do believe the
C++ abstract machine is supposed to be/emulate) will halt.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-05-09 10:14:42