Differences between mutex and semaphore in the s60 System

1. Symbian system threads
The thread of the Symbian system is based on the Symbian microkernel thread and used to support multi-threaded applications in user mode.
. Dthread represents the Symbian system thread. For the user mode, the Symbian Development Environment
Provides the rthread class for conventional thread operations. (Rthread is derived from the rhandlebase class)

The thread object of every Symbian system contains a micro-kernel thread object, which is directly implemented by the kernel.
Scheduled. Each Symbian system thread has two stacks. One is used by the user mode thread and the other is used by the user mode thread.
Used by the microkernel thread. In addition, each Symbian system thread has the following features:
(1) provides a series of executable functions with different execution efficiency for the user mode thread to call various functions of the kernel.
(2) An exception handler
(3) A trap processing function
(4) An exit function
(5) Active sched)
(6) A pointer to the process that creates the current thread (this is a bit of a detour, so you will get used to reading it several times more)
(7) heap of the current thread

The status of the Symbian thread:
The following 10 States are called the M state, which is the full state of threads in the Symbian system:
(1) ecreated: the initial state of the thread
(2) edead: the final state of the thread
(3) eready: The thread is ready to run and can start running immediately.
(Not blocked by any Symbian synchronization objects, such as semaphore and mutex)
Note:
For the microkernel, a thread that is blocked or suspended by the synchronization object (for example, fast semaphore)
It is also possible to enter this status.
(4) ewaitsemaphore: blocks the semaphore object of the waiting system.
(5) ewaitsemaphoresu0000ded: after the current thread is blocked by the system's semaphore, another thread explicitly requires that the current thread be suspended.
(Original article: another thread has explicitly susponded this thread after it blocked on a SOS semaphore .)

(6) ewaitmutex: blocks the mutex object waiting for the system.
(7) ewaitmutexsuincluded: after another thread is blocked by the system mutex, it explicitly requires that the current thread be suspended.
(Original article: another thread has explicitly suincluded this thread after it blocked on a SOS mutex .)

(8) ewaitmutexpending: Wake up from the ewaitmutex status
(9) ewaitcondvar: the conditional variable that blocks the waiting system)
(10) ewaitcondvarsuincluded: after another thread is blocked by the system's condition variable, it explicitly requires that the current thread be suspended.

Each thread has an iwaitobj Object Pointer pointing to the synchronization object that is currently blocking the wait (such as mutex, semaphore,
Or conditional variable)

Note:
The mutex object has three closely related states:
Ewaitmutex, ewaitmutexsuincluded, and ewaitmutexpending.
Therefore, when the two threads that execute the same code segment protected by the mutex object are scheduled by the kernel,
Compared with the code segment protected by the same semaphore object, it has completely different actions.

Assume there is the following code:
Void threadsafefunction ()
{
Tint Index = 0;
For (; index <kloopcount; index ++)
{
Mutex. Wait ();
// Access some global/common data here
Mutex. Signal ();
}
}
We suppose there are two threads (we call them a and B) that execute the same function at the same time.
If a first enters this function, it will execute the mutex. Wait () function
Request the current mutex object, which is preemptible by the kernel scheduler when the mutex application is completed.
In this way, B occupies the CPU. When B enters the same function, B requests the results of the mutex object.
Is the ewaitmutex status. The current mutex is first obtained by. So B will be in the blocking status,
After a period of time (this period of time is very short), when the kernel scheduler is scheduled to A, A starts to restart
Run the command. A releases the requested mutex through mutex. Signal. Note: This does not mean that B will
Block A to continue execution. This signal operation sets the current status of B to ewaitmutexpending.

A will continue to execute until a's CPU time slice times out (20 microseconds by default), or a exits,
Or a is blocked or suspended again for another reason. Even if a has released the mutex that B blocks,
B will not run again.

If semaphore instead of mutex is used in the above functions, the actions will be completely different,
When a releases the current semaphore, B in the ewaitsemaphore status will start immediately.
Continue. In this case, a is blocked because it fails to apply for semaphore again.
Haha, this is because semaphore has only two States (ewaitsemaphore, ewaitsemaphoresuspended)
.