CMSIS RTOSv2 API: Should osThreadSuspend () be allowed to suspend another thread? about cmsis_5

[ilg-ul]

For consistency reasons, I would also rename

osThreadId_t osThisThreadGetId (void);
osStatus_t osThisThreadYield (void);
__NO_RETURN void osThisThreadExit (void *exit_ptr);

Actually all functions that do not have a osThreadId_t parameter refer to the current thread.

In CMSIS++ all functions that refer to the current thread are part of the this_thread namespace (or are prefixed with os_this_thread_ in the C API).

[ReinhardKeil]

There are situations where you want to stop a certain operation, but you do not want to abort it. In this case the suspend is initiated by other threads.

[ilg-ul]

if the purpose is to interrupt a thread, then suspend() is probably the least effective method.

as explained in #67 (and#83), suspend() and resume() are the basic scheduler primitives, and their semantic is to remove/add the thread to the READY list, exposed as the SUSPENDED/READY thread state codes.

suspending a thread does not guarantee that it will be stoped, because immediately after suspend() a timeout may occur, and the thread will be resumed, or even an expected event may occur (if waiting on a semaphore, a post() occurs on interrupts, etc).

stopping/interrupting a thread is a different story (see #68) and, to happen in an orderly manner, requires a two way protocol: one thread requests the interruption and sets a flag, the interrupted thread checks the flag and, if set, aborts what it was doing, and clears the flag. this flag should also be checked by all blocking functions, to cancel the wait and return a specific EINTR code.

I don't know, there might be situations when one thread suspends another, but I would say this usage is the result of a poor design; normally a thread, when nothing to do, removes itself from the ready list and, when an event occurs, some other thread or interrupt puts it back into the ready list.

[JonatanAntoni]

We have updated the thread documentation.

It should be clear now that osThreadSuspend() removes the target thread from the ready list under all circumstances. The thread will be rescheduled after calling osThreadResume, not under any other condition. So a suspended thread should not be resumed on a timeout or a semaphore becoming available.

Btw: To leave it up to the user we decided not to restrict the context a thread can be suspend from. This might be due to a poor design. But we do not want to introduce arbitrary limits on API level.

Please be so kind and close this issue if your questions are answered so far.