Printable View
I have the question about synchronization after looking at some articles in the web.
If I am using mutex for controlling the unique session resource, what will happen if there exists several thread which want to request the session resource which is in use? As I don't know how to put them in queue and how the first waiting get the session resource? It is mainly in coding sample as I want.
The whole point of a mutex is to handle the low-level details of the synchronization process (eg: the 'queueing' that you were referring to) for you. All you have to do is make sure that every access to the data structure is done through that mutex.
Just keep in mind that mutexes are not a total synchronization solution - they can't prevent deadlocks/starvation/etc, for example. For that, there isn't a simple answer. I while back I worked on dependency-detection algorithm, but never quite completed it. That would be the general idea, though, if you were looking for a fool-proof solution...
If two or more threads request the MUTEX object, only one of them gets it, the other thread(s) block until the MUTEX becomes available. When a thread releases a MUTEX object the thread scheduler wakes up the next waiting thread on that object and gives it control of the MUTEX. If a thread acquires the MUTEX and fails to release it, it can cause a deadlock on all other waiting threads.. There is no guarantee that the first thread to wait on the mutex will be the first to get it, but in general the kernel tries to be 'fair'. Meaning one thread wont usually get the mutex twice while another hasnt gotten it once.Quote:
Originally Posted by rchiu5hk
Code:#include <windows.h>
#include <stdio.h>
HANDLE Mutex;
DWORD WINAPI ThreadFunc(LPVOID pThreadNum){
WaitForSingleObject(Mutex , INFINITE);
char myString[256];
sprintf(myString , "Thread #%d Got the MUTEX.\n\0" , *(DWORD*)pThreadNum);
int x = 0;
while(myString[x]){
printf("%c" , myString[x]);
Sleep(rand() % 100 + 100 + (100 * *(DWORD*)pThreadNum));
x++;
}
ReleaseMutex(Mutex);
return 0;
}
DWORD WINAPI AsyncThreadFunc(LPVOID pThreadNum){
// WaitForSingleObject(Mutex , INFINITE);
char myString[256];
sprintf(myString , "Thread #%d Got the MUTEX.\n\0" , *(DWORD*)pThreadNum);
int x = 0;
while(myString[x]){
printf("%c" , myString[x]);
Sleep(rand() % 100 + 100 + (100 * *(DWORD*)pThreadNum));
x++;
}
//ReleaseMutex(Mutex);
return 0;
}
int main(){
DWORD ThreadId = 0;
Mutex = CreateMutex(NULL , FALSE , TEXT("MyMutex"));
DWORD ThreadNumber1 = 0;
HANDLE Thread1 = CreateThread(NULL , 0 , ThreadFunc , (LPVOID)&ThreadNumber1 , 0 , &ThreadId);
DWORD ThreadNumber2 = 1;
HANDLE Thread2 = CreateThread(NULL , 0 , ThreadFunc , (LPVOID)&ThreadNumber2 , 0 , &ThreadId);
WaitForSingleObject(Thread1 , INFINITE);
WaitForSingleObject(Thread2 , INFINITE);
ThreadNumber1 = 0;
Thread1 = CreateThread(NULL , 0 , AsyncThreadFunc , (LPVOID)&ThreadNumber1 , 0 , &ThreadId);
ThreadNumber2 = 1;
Thread2 = CreateThread(NULL , 0 , AsyncThreadFunc , (LPVOID)&ThreadNumber2 , 0 , &ThreadId);
WaitForSingleObject(Thread1 , INFINITE);
WaitForSingleObject(Thread2 , INFINITE);
return 0;
}
Well, that would more appropriately be a simple 'bug' in the program. A true deadlock occurs when, say, thread #1 holds a mutex on resource 'A' and requests object 'B', while at the same time thread #2 holds a mutex on resource 'B' and requests object 'A'. It doesn't have to be that direct, either - it could also happen if T#1 waits for T#2 which waits for T#3 which waits for T#4 which waits for T#1!Quote:
If a thread acquires the MUTEX and fails to release it, it can cause a deadlock on all other waiting threads.
THAT is a bug, it usually occurs because someone didn't do their layout planning for the workflow.Quote:
Originally Posted by Sebastiani
What usually happens is-
Thread1 needs exclusive access to two resources, lets say the DISK and the NETWORK.
Thread 2 needs exclusive access to the NETWORK DISK and an INTERNAL_DATA_STRUCTURE.
Thread3 needs exclusive access to NETWORK and INTERNAL_DATA_STRUCTURE
Thread1 acquires the mutex for teh DISK
Thread2 acquires the mutex for the NETWORK
Thread1 waits forever to acquire the NETWORK because Thread2 has it
Thread2 acquires the mutex for the INTERNAL_DATA_STRUCTURE
Thread2 waits forever to acquire the DISK because Thread1 has it
Thread3 Waits forever to acquire INTERNAL_DATA_STRUCTURE because Thread2 has it
The solution is that a thread must 'reset' if it cannot acquire all the resources it needs, and retry. Generally in cases of mutual dependency, it is bad form to use INFINITE as the wait period, shorter periods should be used and checks performed to determine if the thread has all the required resources. Using the granularity of the system timer as a base time, count the number of potential threads that would simultaneously access a mutex, have each thread wait the system timer resolution before resetting, and upon reset multiply by the timer resolution, and have each thread wait that period of time before attempting to reacquire the resources.
Since MUTEX's are generally used for interprocess resource control, it may not be possible to determine the number of threads that will attempt to access the resource, so waiting a random time before reattempting to acquire will work in those cases.
Well, that's true.Quote:
Originally Posted by abachler
That's a good approach, though if you really want a simple solution to the problem, just use one mutex for all resources (of course this might not be efficient enough in some circumstances). But it does prevent deadlock, and depending on how the mutex is implemented, starvation as well (most modern implementations would probably pass that test, I think).Quote:
Originally Posted by abachler