Shared +Memory between Threads

diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-5FBA9BB1-94A2-470C-9932-C4255E3774C0.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-5FBA9BB1-94A2-470C-9932-C4255E3774C0.dita Thu Jan 21 18:18:20 2010 +0000 @@ -0,0 +1,97 @@ + + + + + +Shared +Memory between ThreadsThis document describes the shared memory between threads and how +to avoid race conditions. +

Shared memory is a method of InterProcess Communication (IPC) where a single +chunk of memory is shared between two or more processes. It is used to communicate +between threads within a process or two unrelated processes, allowing both +to share a given region of memory efficiently. In an SMP system, multiple +cores are running threads at the same time and not just virtually as in unicore. +Extra caution is needed to handle memory that shared between multiple threads.

A thread is the unit of execution within a process. Every time a process +is initialized, a primary thread is created. For many applications the primary +thread is the only one that the application requires, however, processes can +create additional threads. In an SMP system, multiple threads can be executing +the same (shared) functions simultaneously. Therefore functions need to deal +with this situation in order to maintain consistency of the system.

Following are the key concepts to synchronize threads:

Mutexes are used to serialize access to a section of re-entrant +code that cannot be executed concurrently by more than one thread. A mutex +object only allows one thread into a controlled section, forcing other threads +which attempt to gain access to that section to wait until the first thread +has exited from that section. A mutex can be used by threads across any number +of processes. If a resource is only shared between the threads within the +same process, it can be more efficient to use a critical section.

Semaphores restrict the number of simultaneous users of a shared +resource up to a maximum number. Threads can request access to the resource +(decrementing the semaphore), and can signal that they have finished using +the resource (incrementing the semaphore). A thread that requests access to +a busy resource is put in a waiting state. The semaphore maintains a First +In First Out (FIFO) queue of such waiting threads. When another thread increments +the semaphore, the first thread in this queue is resumed.

Locks are used to synchronize the data between threads in the +kernel. In SMP, threads are executed in parallel, which means that if locks +are not applied to the code it could result in a race condition. Race conditions +lead to system crashes and data corruptions. For more information about locking, +see Locking.

Shared memory between threads is provided by the following APIs: + + + +
API name
+
Description
+ + + + +
TFindThread
+
Searches for threads by pattern matching against the names of thread +objects.
+ + +
RThread
+
A handle to a thread.
+ + +
RMutex
+
A handle to a mutex.
+ + +
TFindMutex
+
Finds all global mutexes whose full names match a specified pattern.
+ + +
RSemaphore
+
A handle to a semaphore.
+ + +
TFindSemaphore
+
Finds all global semaphores whose full names match a specified pattern.
+ + + +

+Threads And +Processes Overview +Mutexes Overview + +Semaphores +Overview +

\ No newline at end of file