multithread program with mutexes and semapohres - c

There are 3 series' to compute using multithread.
To access a series you need to wait for semaphore, and after that you need to know if you are builder thread or cleaning thread.
Everything works great when I have num of threads which all of them has what to do and there are no 'floating' thread that cannot access semaphore or mutex.
If I do have too many threads and the dont have what to do the program get stuck unless after WaitSemRes/WaitMutexRes I kill that thread but I dont want to do that bc I loosing to much computing time.
I just want them to keep waiting until they have something to do.
Am I missing something?
/* Thread is trying to enter specific series, if couldnt - try the next one*/
WaitSemRes = WaitForSingleObject(main_series[series_idx].semaphore, 0L);
if (WaitSemRes == WAIT_OBJECT_0) {
/* Check if i'm the cleaning thread */
if (main_series[series_idx].ready_to_clean) {
/* Catching series mutex to clean it alone */
WaitMutexRes = WaitForSingleObject(main_series[series_idx].mutex, INFINITE);
if (WaitMutexRes == WAIT_OBJECT_0)
// do something //
}
else {
ExitThread(0);
}
// do stuff
else {
ExitThread(0);
}

You could use a shutdown event to signalize the threads when there's no more work to be done, this way they can keep waiting indefinitely. It can be created using CreateEvent, then all you need to do is to make your worker threads wait upon it. When you all work is done you can make all threads exit almost simultaneously by using SetEvent, and then wait upon a HANDLE array that contains all the thread handles
For details regarding how to wait on multiple objects you can refer to WaitForMultipleObjects Example
Worker thread
int thread_function(...) {
[...]
while(WaitForSingleObject(thread_shutdown_event, 0) != WAIT_OBJECT_0) {
// Keep trying to process data until the event is signalized
}
// Exit thread
return 0;
}
Pool handling functions
void end_thread_pool(...) {
HANDLE wait_result;
if(thread_shutdown_event == NULL)
return;
// Activate shutdown event
SetEvent(thread_shutdown_event);
// Wait upon thread handle list until all threads can return safely
wait_result = (HANDLE)WaitForMultipleObjects(...);
if(wait_result != WAIT_OBJECT_0) {
// Failed to wait
}
CloseHandle(thread_shutdown_event);
[...]
return;
}
void init_thread_pool(...) {
[...]
thread_shutdown_event = CreateEvent(NULL, // Default security attributes
TRUE, // Manual reset?
FALSE,// Starting value
TEXT("Thread Shutdown event"));// Event name
if(thread_shutdown_event == NULL) {
// Failed to create event
return;
}
// Initiates threads and also puts their HANDLEs in a array
// that is going to be used in end_thread_pool to wait
// See 'WaitForMultipleObjects Example'
thread_create(thread_function, number_of_threads);
[...]
return;
}

Related

Which is the correct way of cancelling main() thread from signal_handler routine?

I am writing a multithreaded server application which echoes back whatever client sends. I am spawning one thread per new client. I have used a while(1) loop to handle successive clients indefinitely (not exactly indefinite, I have forcefully limited it to 64, after which it rejects any new connection). Now I need to handle Ctrl+C signal in my server application.
One problem is that its not recommended to use signal() in multithreaded application.
However, even if I use it to catch the SIGINT signal (from Ctrl+C) using the method already discussed at SO this is what I need to do:
1) The server should no longer accept more clients.
2) The present connections to server should continue, except when client choses to disconnect.
My signal handler function is:
void Ctrl_C_handler(int sig)
{
if(sig == SIGINT) // Ctrl+C
{
printf("Ctrl+C detected by server !!\n");
printf("No more connections will be accepted!!");
pthread_cancel(main_thread_id);
}
}
The methods I propose to use inside main() to cancel the thread are:
// Method 1
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
while(1)
{
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
// ..
// client handling
// ..
}
// Method 2
while(1)
{
pthread_testcancel(); // Create Cancellation point
// ..
// client handling
// ..
}
// Method 3
while(1)
{
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_testcancel();
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
// ..
// client handling
// ..
}
Reason for why I am using pthread_cancel():
According to this link the thread will be finally terminated using pthread_exit() (Requirement 1 fulfilled). Since the NOTES section of pthread_exit() explains that it allows other threads to continue execution (Requirement 2 fulfilled).
Now if I am right till here,
Which method is best for cancellation of thread.
I chose method 3 because:
(Demerits) Method 1: Asynchronous thread cancel is not safe (as I saw in an answer in SO) if the thread allocates memory, and few other reasons
(Demerits) Method 2: According to this link there are so many other functions which can also work as cancellation points, some of those I will be using in my code.
(Merits) Method 3: Similar to method 2 but safer because other cancellation points will not be active since thread is cancel disabled.
Please tell me if my way is correct or not? And its wrong, is there any other better method to handle Ctrl+C similarly other than using pthread_cancel()?
I'd suggest avoiding cancellation.
Instead, register a SIGINT handler that close()s the server's listening socket. (Use sigaction for this.) The main thread can quit gracefully after the socket is closed, leaving any client threads running.
E.g. in pseudocode:
static int listen_fd = -1 // server socket
void handle_SIGINT(int s): // Requirement 1
if listen_fd >= 0:
close(listen_fd)
listen_fd = -1
int main(...):
listen_fd = new_listening_socket(...)
block_signal(SIGINT)
trap_signal(SIGINT, handle_SIGINT) // again, calls sigaction
while 1:
unblock_signal(SIGINT)
new_client = accept(listen_fd)
block_signal(SIGINT)
if new_client < 0: // Requirement 1, also general error handling
break
spawn_worker_thread(new_client) // probably attr PTHREAD_CREATE_DETACHED
pthread_exit(NULL) // Requirement 2
return 0 // not reached
You can of course include more nuanced error handling, cleanup routines, etc., as needed.

Sharing data between master thread and slave thread in interrupt driven environment in C

I have the following:
f1()
{
while(1)
{
call f(2) if hardware interrupt pin goes high
}
}
f2()
{
if( th() not started )
{
start thread th()
}
else
{
return thread th() status
}
}
th()
{
time-consuming operation
}
At the moment, I use the following to initiate a struct in f2():
static struct SharedData shared;
if( shared == NULL)
{
initialize shared
}
Then I pass a pointer to shared to the thread. The thread then updates shared periodically. f2() will then know if th() has been started based on elements of shared and it will check the status of th() by reading from shared.
Let's assume one of the elements of shared is a mutex to provide thread safety. Is this a good solution? Is there a more elegant way of doing this? I have tested the code and it works. I just need some expert advice here.
Thanks,
Assuming that f2() uses the same mutex in the shared structure to lock before reading the data that the thread th uses to modify the data, I don't see any issues.
If you have more than one thread calling f2(), you may want to use a read-write lock for reading and writing of the thread status of th. The mutex could still be used to serialize the thread creation check. You could also use a pthread_rwlock_wrlock() to serialize th creation, but the code is arguably less clear.
Using a mutex to serialize th creation in f2():
pthread_rwlock_rdlock(&shared.rwlock);
result = shared.th_status;
if (! shared.th_created) {
pthread_mutex_lock(&shared.mutex);
if (! shared.th_created) {
pthread_create(...);
shrared.th_created = 1;
}
pthread_mutex_unlock(&shared_mutex);
}
pthread_rwlock_unlock(&shared.rwlock);
return result;
Using the read-write lock to serialize th creation in f2():
pthread_rwlock_rdlock(&shared.rwlock);
result = shared.th_status;
if (! shared.th_created) {
pthread_rwlock_unlock(&shared.rwlock);
pthread_rwlock_wrlock(&shared.rwlock);
if (! shared.th_created) {
pthread_create(...);
shrared.th_created = 1;
}
}
pthread_rwlock_unlock(&shared.rwlock);
return result;

Making unknown number of child threads inside parent thread using win32 in C?

How can I make unknown number of child threads inside parent thread and wait for each of them one by one using win32 in C?
The parent thread life time is infinite and it is wait for request and if received any request then make a new child thread for that request e.g. like servers .
I am searching the web but I cant find anything .
Any tutorial and information appreciated .
Thanks a lot , good luck .
note :
1 . For example imagine a simple server : When a user send a request to that server the server make a new thread for that user and wait for that thread to terminated but if another user send another request the server make another thread which is completely separate from the old one and then the server must wait for the new thread separate from the old one to terminate .
2 . The main thread scan an global array with the size of constant n in the infinite loop and if find the specific value in each of array's block then run the new thread to do some operation on that block's information and then after the thread become terminate update that block's information . The parent thread life time is infinite because it has a infinite loop .
You'ld create each thread with CreateThread and store the thread handle in a dynamic list or array. If you want the main thread to recognize when a thread terminated, then you can call WaitForMultipleObjects, providing it an array with all thread handles. The return value of WaitForMultipleObjects will tell you which thread handles was signalled, so which thread terminated. Don't forget to CloseHandle the thread handle at the end.
If you just want to spawn threads and the main thread does not need to know when the threads terminate, then you can just create the threads with CreateThread and close the thread handle. The thread's resources will be freed when the thread terminates.
In your main thread you will also need to check if you receive a client request. If you have an Interface to the client where you can wait on an event, then just add the event to the event array passed to WaitForMultipleObjects. If you do not have an event like in your case 2, then you might consider calling WaitForMultipleObjects with a timeout so WaitForMultipleObjects either returns when a thread terminated or when the timeout occured. In both cases your main loop keeps running and you can check if you need to spawn another thread.
Here is some pseudo code when using an event for the client requests:
initialize empty list of thread data (thread handles and other data for each thread);
for(;;) {
create an array a big enough for the request event and for all thread handles;
a[0] = request event handle;
a[1..n] = thread handles from the list;
DWORD ret = WaitForMultiObjects(n+1, a, FALSE, INFINITE);
if(ret == WAIT_OBJECT_0) {
create thread and store it's handle and other data in the list;
}
else if(WAIT_OBJECT_0 + 1 <= ret && ret <= WAIT_OBJECT_0 + n) {
thread (ret - WAIT_OBJECT_0 - 1) terminated, do your cleanup and don't forget CloseHandle();
}
else
error occured, should not happen;
}
If you don't have an event for the client requests, then you need to poll:
initialize empty list of thread data (thread handles and other data for each thread);
for(;;) {
create an array a big enough for the request event and for all thread handles;
a[0..n-1] = thread handles from the list;
DWORD ret = WaitForMultiObjects(n, a, FALSE, your desired timeout);
if(ret != WAIT_TIMEOUT)
; // timeout occured, no thread terminated yet, nothing to do here
else if(WAIT_OBJECT_0 <= ret && ret < WAIT_OBJECT_0 + n) {
thread (ret - WAIT_OBJECT_0) terminated, do your cleanup and don't forget CloseHandle();
}
else
error occured, should not happen;
// Always check for client requests, not only in case of WAIT_TIMEOUT.
// Otherwise you might run into the situation that every time you call WaitForMultiObjects a thread ended just before the timeout occured and you only recognize it after a lot of loop runs when the last thread terminated.
if(there is a client request) {
create thread and store it's handle and other data in the list;
}
}
If you do not need to store extra data for each thread, then you can just store the thread handles and maybe already store them in a big array. Thus you could eliminate the step to build an array from the thread handle list.
Maybe yo should use the WaitForMultipleObjects function.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx

Creating and destroying threads

gcc (GCC) 4.6.3
c89
Hello,
I am just wondering if this is the best way to handle worker/background threads created by main?
I am doing this right? this is the first time I have done any multiple threading programs. Just want to make sure I am on the right track, as this will have to be extended to add more threads.
I have one thread for sending a message and another for receiving the message.
Many thanks for any suggestions,
int main(void)
{
pthread_t thread_send;
pthread_t thread_recv;
int status = TRUE;
/* Start thread that will send a message */
if(pthread_create(&thread_send, NULL, thread_send_fd, NULL) == -1) {
fprintf(stderr, "Failed to create thread, reason [ %s ]",
strerror(errno));
status = FALSE;
}
if(status != FALSE) {
/* Thread send started ok - join with the main thread when its work is done */
pthread_join(thread_send, NULL);
/* Start thread to receive messages */
if(pthread_create(&thread_recv, NULL, thread_receive_fd, NULL) == -1) {
fprintf(stderr, "Failed to create thread for receiving, reason [ %s ]",
strerror(errno));
status = FALSE;
/* Cancel the thread send if it is still running as the thread receive failed to start */
if(pthread_cancel(thread_send) != 0) {
fprintf(stderr, "Failed to cancel thread for sending, reason [ %s ]",
strerror(errno));
}
}
}
if(status != FALSE) {
/* Thread receive started ok - join with the main thread when its work is done */
pthread_join(thread_recv, NULL);
}
return 0;
}
Example of a worker/background thread to send a message, example only
void *thread_send_fd()
{
/* Send the messages when done exit */
pthread_exit(NULL);
}
The only time when this kind of construct might be justified is if there is only ever one message exchanged and, even then, there may be some problems.
If messages are to be exchanged continually during the app run, it's more usual to write both threads as loops and never terminate them. This means no continual create/terminate/destroy overhead and no deadlock-generator, (AKA join). It does have a downside - it means that you have to get involved with signals, queues and the like for inter-thread comms, but this is going to happen anyway if you write many multithreaded apps.
Either way, it's usual to start the rx thread first. If you start the tx thread first, there is a possibility that rx data will be retuned and discarded before the rx thread starts.
Is this done once per message? It seems like the call creates a thread to send 1 message and another thread to wait for 1 response. Then the call, and I'm assuming the entire program, just waits for the whole thing to finish. Assuming the receiver cannot do anything until the sender finishes sending, this does absolutely nothing to improve the real or perceived performance of your program. Now to be precise, we would need to know what the sender and the receiver are really doing before we can tell for sure if there is any benefit from this. For any benefit at all, the sender thread and the receiver thread would have to have work that they can do simultaneously....not serially. If the intent is to not make the program wait for the send and the receive transaction, then this does not do that at all.

Conditional wait with pthreads

I seem to be running in to a possible deadlock with a pthreads conditional variable.
Here is the code
thread function(){
for (condition){
do work
/* should the thread continue? */
if (exit == 1){
break; /* exit for */
}
} /* end for */
pthread_mutex_lock(&mtxExit);
exit = 0;
pthread_cond_signal(&condVar);
pthread_mutex_unlock(&mtxExit);
}
The main function is as follows:
function main(){
if (thread is still active){
pthread_mutex_lock(&mtxExit);
exit = 1;
pthread_mutex_unlock(&mtxExit);
} /* end if */
while (exit == 1){
pthread_mutex_lock(&mtxExit);
/* check again */
if (exit == 1)
pthread_cond_wait(&condVar, &mtxExit);
pthread_mutex_unlock(&mtxExit);
}
create new thread()
....
}
The code is always getting stuck at cond_wait. :(
EDIT:
Let me add some clarification to the thread to explain what I am doing.
At any given time, I need only one thread running. I have a function that starts the thread, tells it what to do and the main thread continues it work.
The next time the main thread decides it needs to spawn another thread, it has to make sure the thread that was previously started has exited. I cannot have two threads alive at the same time as they will interfere with each other. This is by design and by definition of the problem I am working on.
That is where I am running in to problems.
This is my approach:
Start the thread, let it do its job.
the thread checks in every step of its job to see if it is still relevant. This is where "exit" comes in to picture. The main thread sets "exit" to 1, if it needs to tell the thread that it is no longer relevant.
In most cases, the thread will exit before the main thread decides to spawn another thread. But I still need to factor in the case that the thread is still alive by the time the main thread is ready to start another one.
So the main thread sets the value of "exit" and needs to wait for the thread to exit. I dont want to use pthread_kill with 0 as signal because then main thread will be in a loop wasting CPU cycles. I need the main thread to relinquish control and sleep/wait till the thread exits.
Since I only need one thread at a time, I dont need to worry about scaling to more threads. The solution will never have more than one thread. I just need a reliable mechanism to test if my thread is still alive, if it is, signal it to exit, wait for it to exit and start the next one.
From my testing, it looks like, the main thread is still entering the conditional variable even if the thread may have exited or that the signal is not getting delivered to the main thread at all. And its waiting there forever. And is some cases, in debugger I see that the value of exit is set to 0 and still the main thread is waiting at signal. There seems to be a race condition some where.
I am not a fan of how I set up the code right now, its too messy. Its only a proof of concept right now, I will move to a better solution soon. My challenge is to reliably signal the thread to exit, wait on it to exit.
I appreciate your time.
Did you forget to initialize your condition variable?
pthread_cond_init(&condVar, NULL)
while (exit == 1) {
In the code you quote, the way you quote I do not see any particular problem. It is not clean, but it appears functional. What leads me to believe that somewhere else you are setting exit to 0 without signaling that. Or the thread is getting stuck somewhere doing the work.
But considering the comments which hint that you try to signal one thread to terminate before starting another thread, I think you are doing it wrong. Generally pthread condition signaling shouldn't be relied upon if a signal may not be missed. Though it seems that state variable exit covers that, it is still IMO wrong application of the pthread conditions.
In the case you can try to use a semaphores. While terminating, the thread increments the termination semaphore so that main can wait (decrement) the semaphore.
thread function()
{
for (condition)
{
do work
/* should the thread continue? */
if (exit == 1) {
break; /* exit for */
}
} /* end for */
sem_post(&termSema);
}
function main()
{
if (thread is still active)
{
exit = 1;
sem_wait(&termSema);
exit = 0;
}
create new thread()
....
}
As a general remark, I can suggest to look for some thread pool implementations. Because using a state variable to sync threads is still wrong and doesn't scale to more than one thread. And error prone.
When the code is stuck in pthread_cond_wait, is exit 1 or 0? If exit is 1, it should be stuck.
If exit is 0, one of two things are most likely the case:
1) Some code set exit to 0 but didn't signal the condition variable.
2) Some thread blocked on pthread_cond_wait, consumed a signal, but didn't do whatever it is you needed done.
You have all sorts of timing problems with your current implementation (hence the problems).
To ensure that the thread has finished (and its resources have been released), you should call pthread_join().
There is no need for a pthread_cond_t here.
It might also make more sense to use pthread_cancel() to notify the thread that it is no longer required, rather than a flag like you are currently doing.
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *thread_func(void *arg) {
int i;
for (i = 0; i < 10; i++) {
/* protect any regions that must not be cancelled... */
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
/* very important work */
printf("%d\n", i);
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
/* force a check to see if we're finished */
pthread_testcancel();
/* sleep (for clarity in the example) */
sleep(1);
}
return NULL;
}
void main(void) {
int ret;
pthread_t tid;
ret = pthread_create(&tid, NULL, thread_func, NULL);
if (ret != 0) {
printf("pthread_create() failed %d\n", ret);
exit(1);
}
sleep(5);
ret = pthread_cancel(tid);
if (ret != 0) {
printf("pthread_cancel() failed %d\n", ret);
exit(1);
}
ret = pthread_join(tid, NULL);
if (ret != 0) {
printf("pthread_join() failed %d\n", ret);
exit(1);
}
printf("finished...\n");
}
It's also worth noting:
exit() is a library function - you should not declare anything with the same name as something else.
Depending on your specific situation, it might make sense to keep a single thread alive always, and provide it with jobs to do, rather than creating / cancelling threads continuously (research 'thread pools')

Resources