Need a "monitor" spin-for-ISR API

[andyross]

Discussion in #8368 showed that some drivers have a need for a "wait for an ISR" behavior in their normally-threaded APIs. Most of them use a semaphore for this, which works very well.

Nonetheless, when CONFIG_MULTITHREADING=n is set, semaphores and other IPC APIs cannot be used. Yet this kind of driver behavior may still be required.

One option would be to provide a "monitor" API which can be trivially implemented by a spin loop (but ideally would work via some kind of platform power management feature like x86's MONITOR/MWAIT).

Consider:

struct k_monitor { /* arch-specific */ };

/**
 * Busy-wait (ideally in an architecturally-defined low power state)
 * for another CPU or ISR to call k_signal_monitor(), then returns.
 * May return spuriously (for example, after unrelated interrupts) and
 * must be used in a loop.
 */
void k_monitor_wait(struct k_monitor *monitor);

/**
 * Signal any waiters on the address (either on this CPU in a preempted
 * context or on another CPU) to return from k_monitor_wait()
 */
void k_signal_monitor(struct k_monitor *monitor);

[hongshui3000]

CONFIG_MULTITHREADING=n is set.

I have 3 drivers started but there is no correlation between them. Each driver needs for a "wait for an ISR".

such as:

driver A --> wait isr (1s) --> A do something --> B --> wait isr (1s) -->  B do something --
 -->C--> wait isr (1s) -->C do something --> Finished 

I need more than 3s to accomplish this.

It takes time to complete this

I think the time-saving process should be:

[andyross]

Turning serial initialization into parallel initialization is just a hard problem in general. But note that your situation could be addressed with this API: all three drivers could be configured to signal the same monitor on "initialization complete", and you could spin on all of them in the main thread.

[hongshui3000]

@andyross thanks for your advice
I still have an idea:
Can work_q be enhanced so that it can work in single thread, my driver interrupts the submission of work items, and waits for and processes work items in the main thread.
If the work queue can support priority scheduling (prior work items can be prioritized), we can do more complex work in a single thread.

[andyross]

No. A work_q is a thread. Really you can't do anything with any of the kernel synchronization primitives when CONFIG_MULTITHREADING=n. No semaphores, work_q's, fifos/lifos, stacks, msgq's, mailboxes, mutexes. All of that stuff is predicated on the idea of structuring an application as a bunch of threads that can be blocked to wait on other threads.

All you can do in a single thread is handle interrupts and poll for changes. It's a very different programming model, not really "Zephyr".

[nashif]

@ hongshui3000 are you using CONFIG_MULTITHREADING=n with mcuboot?

[hongshui3000]

No. @nashif My application generally uses single-threaded, in order to save code and memory usage. Sometimes the benefits of multithreading are not needed due to cost. I generally use only a simple message scheduling mechanism to complete my application. So I hope zephyr will be easier to develop applications in a single thread. Zephyr now supports single-threaded, but development in this case is not easy.If zephyr can provide a complete single-threaded application development framework, it will be of great help to me.

My needs:
1 single thread memory management mechanism
2 single thread message distribution mechanism

[andyross]

(Doing a grooming pass on bugs/issues that are sitting around with my name on or near them. No one pays me right now so I get to be an unaccountable whirlwind of chaos!)

Closing. MULTITHREADING=n keeps going around and around as to what kind of support it wants. But IMHO it's clear we won't be adding any new synchronization primitives[1] for it alone.

[1] At least, not until someone wants to rework the backend so {k,sys}_{futex,mutex,sem} can all share the same core code! There's an issue to that effect somewhere too, and a spin-polled/single-thread lock could be viewed as a feature to that.