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.
Related
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.
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
gcc (GCC) 4.6.3
valgrind-3.6.1
I have created a application that send and receives some messages in 2 different thread for sending and receiving. Using pthreads, condition varables and mutexes for locks.
However, the sender will send messages and then signal the receiver to receive it and process it. It does this in a while loop.
However, the problem occurs if I want to quit the application by using ctrl-c and handling the interupt. If there is no messages being sent then the receiver is stuck in the while loop waiting to receive.
The main thread will call join and block waiting for the receiver to finish. But it doesn't as it waiting on the pthread_cond_wait.
I was thinking of using the pthread_cancel or pthread_kill. But I don't like to do that as it doesn't allow the thread to exit normally.
many thanks for any suggestions.
main function
void main(void)
{
/* Do some stuff here */
/* Start thread that will send a message */
if(pthread_create(&thread_recv_id, &thread_attr, thread_recv_fd, NULL) == -1) {
fprintf(stderr, "Failed to create thread, reason [ %s ]",
strerror(errno));
break;
}
printf("Start listening for receiving data'\n");
/* Start thread to receive messages */
if(pthread_create(&thread_send_id, &thread_attr, thread_send_fd, NULL) == -1) {
fprintf(stderr, "Failed to create thread for receiving, reason [ %s ]",
strerror(errno));
break;
}
/* Clean up threading properties */
pthread_join(thread_send_id, NULL);
pthread_join(thread_recv_id, NULL); <---- blocking here waiting for the recv thread to finish
pthread_mutex_destroy(&mutex_queue);
pthread_cond_destroy(&cond_queue);
return 0;
}
sender thread
void *thread_send_fd()
{
pthread_mutex_lock(&mutex_queue);
if(send_fd((int)fd) == FALSE) {
/* Just continue to send another item */
continue;
}
/* Signal the waiting thread to remove the item that has been sent */
pthread_cond_signal(&cond_queue);
pthread_mutex_unlock(&mutex_queue);
}
receiver thread
void *thread_recv_fd()
{
while(is_receiving()) {
pthread_mutex_lock(&mutex_queue);
/* Wait for an item to be sent on the queue */
pthread_cond_wait(&cond_queue, &mutex_queue); <---- waiting here
queue_remove();
pthread_mutex_unlock(&mutex_queue);
}
pthread_exit(NULL);
}
You basically have 3 choices:
Use pthread_cancel. This will interrupt the pthread_cond_wait call, and then exit the thread, invoking the cancellation handlers registered with pthread_cleanup_push on the way up.
Use pthread_kill to send a signal to the thread. This doesn't "kill" the thread, it just sends a signal. In this case, you must have registered a signal handler in that thread for the signal you use, and that signal handler must do something to tell the thread to exit. This isn't particularly better than the third option, since the signal handler still needs to do something to make the pthread_cond_wait loop exit.
Add a manual interruption feature to your thread that knows to set a flag and signal the condition variable. The loop around pthread_cond_wait should then check the flag and exit the thread if the flag is set.
I would recommend (1) or (3). Using pthread_cancel is most generic, but requires careful handling in the thread to ensure there are suitable pthread_cleanup_push calls for cleaning up all resources allocated by the thread, unlocking all mutexes, and so forth. Writing a manual interruption feature is potentially more work, but can be most easily tailored to your application.
I discovered an issue with thread implementation, that is strange to me. Maybe some of you can explain it to me, would be great.
I am working on something like a proxy, a program (running on different machines) that receives packets over eth0 and sends it through ath0 (wireless) to another machine which is doing the exactly same thing. Actually I am not at all sure what is causing my problem, that's because I am new to everything, linux and c programming.
I start two threads,
one is listening (socket) on eth0 for incoming packets and sends it out through ath0 (also socket)
and the other thread is listening on ath0 and sends through eth0.
If I use threads, I get an error like that:
sh-2.05b# ./socketex
Failed to send network header packet.
: Interrupted system call
If I use fork(), the program works as expected.
Can someone explain that behaviour to me?
Just to show the sender implementation here comes its code snippet:
while(keep_going) {
memset(&buffer[0], '\0', sizeof(buffer));
recvlen = recvfrom(sockfd_in, buffer, BUFLEN, 0, (struct sockaddr *) &incoming, &ilen);
if(recvlen < 0) {
perror("something went wrong / incoming\n");
exit(-1);
}
strcpy(msg, buffer);
buflen = strlen(msg);
sentlen = ath_sendto(sfd, &btpinfo, &addrnwh, &nwh, buflen, msg, &selpv2, &depv);
if(sentlen == E_ERR) {
perror("Failed to send network header packet.\n");
exit(-1);
}
}
UPDATE: my main file, starting either threads or processes (fork)
int main(void) {
port_config pConfig;
memset(&pConfig, 0, sizeof(pConfig));
pConfig.inPort = 2002;
pConfig.outPort = 2003;
pid_t retval = fork();
if(retval == 0) {
// child process
pc2wsuThread((void *) &pConfig);
} else if (retval < 0) {
perror("fork not successful\n");
} else {
// parent process
wsu2pcThread((void *) &pConfig);
}
/*
wint8 rc1, rc2 = 0;
pthread_t pc2wsu;
pthread_t wsu2pc;
rc1 = pthread_create(&pc2wsu, NULL, pc2wsuThread, (void *) &pConfig);
rc2 = pthread_create(&wsu2pc, NULL, wsu2pcThread, (void *) &pConfig);
if(rc1) {
printf("error: pthread_create() is %d\n", rc1);
return(-1);
}
if(rc2) {
printf("error: pthread_create() is %d\n", rc2);
return(-1);
}
pthread_join(pc2wsu, NULL);
pthread_join(wsu2pc, NULL);
*/
return 0;
}
Does it help?
update 05/30/2011
-sh-2.05b# ./wsuproxy 192.168.1.100
mgmtsrvc
mgmtsrvc
Failed to send network header packet.
: Interrupted system call
13.254158,75.165482,DATAAAAAAmgmtsrvc
mgmtsrvc
mgmtsrvc
Still get the interrupted system call, as you can see above.
I blocked all signals as followed:
sigset_t signal_mask;
sigfillset(&signal_mask);
sigprocmask(SIG_BLOCK, &signal_mask, NULL);
The two threads are working on the same interfaces, but on different ports. The problem seems to appear still in the same place (please find it in the first code snippet). I can't go further and have not enough knowledge of how to solve that problem. Maybe some of you can help me here again.
Thanks in advance.
EINTR does not itself indicate an error. It means that your process received a signal while it was in the sendto syscall, and that syscall hadn't sent any data yet (that's important).
You could retry the send in this case, but a good thing would be to figure out what signal caused the interruption. If this is reproducible, try using strace.
If you're the one sending the signal, well, you know what to do :-)
Note that on linux, you can receive EINTR on sendto (and some other functions) even if you haven't installed a handler yourself. This can happen if:
the process is stopped (via SIGSTOP for example) and restarted (with SIGCONT)
you have set a send timeout on the socket (via SO_SNDTIMEO)
See the signal(7) man page (at the very bottom) for more details.
So if you're "suspending" your service (or something else is), that EINTR is expected and you should restart the call.
Keep in mind if you are using threads with signals that a given signal, when delivered to the process, could be delivered to any thread whose signal mask is not blocking the signal. That means if you have blocked incoming signals in one thread, and not in another, the non-blocking thread will receive the signal, and if there is no signal handler setup for the signal, you will end-up with the default behavior of that signal for the entire process (i.e., all the threads, both signal-blocking threads and non-signal-blocking threads). For instance, if the default behavior of a signal was to terminate a process, one thread catching that signal and executing it's default behavior will terminate the entire process, for all the threads, even though some threads may have been masking the signal. Also if you have two threads that are not blocking a signal, it is not deterministic which thread will handle the signal. Therefore it's typically the case that mixing signals and threads is not a good idea, but there are exceptions to the rule.
One thing you can try, is since the signal mask for a spawned thread is inherited from the generating thread, is to create a daemon thread for handling signals, where at the start of your program, you block all incoming signals (or at least all non-important signals), and then spawn your threads. Now those spawned threads will ignore any incoming signals in the parent-thread's blocked signal mask. If you need to handle some specific signals, you can still make those signals part of the blocked signal mask for the main process, and then spawn your threads. But when you're spawning the threads, leave one thread (could even be the main process thread after it's spawned all the worker threads) as a "daemon" thread waiting for those specific incoming (and now blocked) signals using sigwait(). That thread will then dispatch whatever functions are necessary when a given signal is received by the process. This will avoid signals from interrupting system calls in your other worker-threads, yet still allow you to handle signals.
The reason your forked version may not be having issues is because if a signal arrives at one parent process, it is not propagated to any child processes. So I would try, if you can, to see what signal it is that is terminating your system call, and in your threaded version, block that signal, and if you need to handle it, create a daemon-thread that will handle that signal's arrival, with the rest of the threads blocking that signal.
Finally, if you don't have access to any external libraries or debuggers, etc. to see what signals are arriving, you can setup a simple procedure for seeing what signals might be arriving. You can try this code:
#include <signal.h>
#include <stdio.h>
int main()
{
//block all incoming signals
sigset_t signal_mask;
sigfillset(&signal_mask);
sigprocmask(SIG_BLOCK, &signal_mask, NULL);
//... spawn your threads here ...
//... now wait for signals to arrive and see what comes in ...
int arrived_signal;
while(1) //you can change this condition to whatever to exit the loop
{
sigwait(&signal_mask, &arrived_signal);
switch(arrived_signal)
{
case SIGABRT: fprintf(stderr, "SIGABRT signal arrived\n"); break;
case SIGALRM: fprintf(stderr, "SIGALRM signal arrived\n"); break;
//continue for the rest of the signals defined in signal.h ...
default: fprintf(stderr, "Unrecognized signal arrived\n");
}
}
//clean-up your threads and anything else needing clean-up
return 0;
}
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')