Move mutex block atomic

[vicLin8712]

mutex_block_atomic() performs task state transitions and enqueues the current task into a waiting queue. Its behavior is analogous to _sched_block(), which is used by semaphore blocking and serves the same purpose of transitioning a task into a blocked state.

For consistency, both task-blocking primitives should be managed under task.c. This commit moves mutex_block_atomic() to task.c and adds its prototype to task.h for use by mutex.c.

No functional changes are introduced.

---

Summary by cubic

Moved mutex_block_atomic() to task.c to keep task-blocking primitives together with _sched_block(). Added its prototype to task.h for use by mutex.c; no functional changes.

^{Written for commit 67d15d8. Summary will update automatically on new commits.}

[jserv]

Is it necessary to expose this function?

[vicLin8712]

The task transition into the blocked state caused by either a semaphore wait or a mutex lock is conceptually similar.

In the semaphore path, the public internal API _sched_block() is used in mo_sem_wait(). In the mutex path, however, we currently use the inline helper mutex_block_atomic().

My intention is to align both task-blocking paths so that semaphore and mutex follow a consistent blocking workflow. However, _sched_block() and mutex_block_atomic() differ slightly in their input parameters and in the fact that mutex does not need to process deferred tasks, so I cannot directly replace the mutex path with _sched_block() even though their high-level functionality—blocking the current task—is largely the same.

Because of that, I moved mutex_block_atomic() into task.c so that both semaphore and mutex blocking primitives are located under the same task state transition module, keeping the call paths consistent.

[HeatCrab]

Hi, regarding the consistency between _sched_block() and mutex_block_atomic():

I noticed that Semaphore operates on a fixed-size queue_t (Ring Buffer), whereas Mutex uses a list_t (Linked List).

Since the underlying data structures are fundamentally different, I wonder if moving the function achieves architectural consistency, or if it just collocates two distinct implementations? I thought this distinction might be worth considering.

[vicLin8712]

Hi, regarding the consistency between _sched_block() and mutex_block_atomic():

I noticed that Semaphore operates on a fixed-size queue_t (Ring Buffer), whereas Mutex uses a list_t (Linked List).

Since the underlying data structures are fundamentally different, I wonder if moving the function achieves architectural consistency, or if it just collocates two distinct implementations? I thought this distinction might be worth considering.

Hi @HeatCrab,

I’m still a bit unclear about the intended role of _sched_block().

Currently, _sched_block() is declared in task.h and used by the semaphore path to atomically block the current task. Mutex, however, uses its own internal helper to block the current task instead of calling _sched_block().

According to the comment in task.h:

/* Atomically blocks the current task and invokes the scheduler.
 *
 * This internal kernel primitive is the basis for all blocking operations. It
 * must be called from within a NOSCHED_ENTER critical section. It enqueues the
 * current task, sets its state to blocked, and calls the scheduler. The
 * scheduler lock is NOT released by this function; it is released implicitly
 * when the kernel context switches to a new task.
 *
 * @wait_q : The wait queue to which the current task will be added
 */

I'm trying to figure out why block process in mutex use inner helper function rather than this _sched_block API.
I think different block path will cause task state transition to become more complex.

But the difficulty that I'm encountering now, as you say, _sched_block() operates on different data structures
to what block in mutex operated on.

[vicLin8712]

Converted to draft for further discussion.