Situation:
I have a thread pool of 64 threads. I have a shared buffer, in which I put and get "works" in a synchronous and organized way. As a normal thread pool should work. It all works fine.
Problem:
Inside main(), I want to put a work in the shared buffer and I want a thread in the thread pool to execute it. However, I need main() to wait before that thread finishes that work. Normally I would pthread_join() it, but i don't know which thread is running the work.
Sorry if I didn't make myself very clear, but I hope you can help me.
Thanks in advance!
Include a synchro object,(eg. semaphore), in the work struct. Issue the work and wait on the synchro. Have the pool threads signal the synchro when they have finished. Don't go near join() unless at gunpoint.
Related
I am trying to make RPC calls to a daemon.
Now the issue is. I want to make multiple async RPC calls, that'd choke the message buffer. So I want to do it one by one.
what I am following
bool wait;
success(){
// On success from send_to_single_peer this will run
wait = false;
}
send_to_single_peer(peer){
wait = true
//makes an RPC call for sendcustommsg to a peer and goes to sucess function
}
sendmultipleasync(){
for(//conditions) {
send_to_single_peer(peer[i]);
do{}
while(wait)
}
}
But this isn't working. What should I do? I've heard multithreading can help me in this case. But I don't know about that much.
I think you need. Your function has the name async in it, so why not do it async.
create a worker thread
create a mutex
make the worker thread lock the mutex
for every peer:
send the request
did it work? if not try again
unlock the mutex (all done)
While you are doing that, you can check if the worker thread is done by using pthread_mutex_trylock. If you just want to wait until it is done use pthread_mutex_lock. NEVER USE while (pthread_mutex_trylock(mutex)); TO DO THAT.
I've heard multithreading can help me in this case. But I don't know about that much.
Basically, with threads you can execute code in parallel. The problem is, that they share the heap memory and are able to modify the variables while the other threads are trying to use them. This will lead to problems really hard to debug, sometimes they only occur one time in a million, because they depend on timing. To prevent access at the same time you can use a mutex. It is kind of a lock for threads. A mutex can only be locked once at a time. One thread for example can lock a mutex while changing a variable. The other thread can try to lock it too. This will cause it to block until the first thread unlocks the mutex. After that block the second thread can read the variables and unlock the mutex after that.
Read a tutorial on threads, they are a really useful took.
Basically, I just want to create a pthread for each number of threads available on the machine, without doing any work. I want to somehow block each one at the start and add it to a threadpool so I can pull an available pthread from the pool when I need work to be done.
How do I go about blocking without having a pthread doing any work? I've tried a dummy function but that doesn't seem to work.
Thanks
Just have it start off by waiting on the work queue. This would normally involve pthread_cond_wait or sem_wait or similar depending on what type of synchronization primitives you're using to manage the work queue.
I'd like to kill a thread from another thread and I'd like to do when it is running, so it won't be anything like change the loop variable to something. What would be the most appropriate way to do it?
To be more clear, I am using cURL and after some point i don't want curl to perform downloading. curl API does not provide anything like that. So I have to cancel the thread.
Killing a thread is rarely a good idea because it can very easily lead to memory/resource leaks. A killed thread only cleans up it's stack and the memory used by the thread itself, nothing allocated via new/malloc etc.
However, if you really want to kill the thread, with pthreads the correct way to do it is to call pthread_cancel.
Also: look here:
Cancelling a thread using pthread_cancel : good practice or bad
I'm working on a filesystem project based on FUSE. And I want to add some sort of read ahead to it. So I create a thread to process such tasks, but It seems that I made it really slower than I thought.(Even if I just add a idle thread, it makes my program become much more slower than without that, but that do not happened when I added this function to my server program, which do not use fuse)
I did not simply use fuse_main function, instead I read the sshfs's code and try to initialize it by myself with the following functions,
fuse_parse_cmdline
fuse_mount
fcntl
fuse_new
fuse_daemonize
fuse_set_signal_handlers
fuse_loop_mt
and without add the thread, it runs pretty well, but after I add this thread in
pthread_create(&tid, NULL, test, NULL); // function test is just a while(1){}
it get slower(Read a 100M file, without this thread it is 40s, and with that it is nearly 100s)
Is this something to do about schedparam or something else?
Hope you guys could give me some advice, like what things I need to check.
Thanks again.
Your thread is busy waiting, which means it will use as much CPU power as it can. You might want to add a little delay in your thread to let other threads and processes run too:
while (1)
{
usleep(1000); /* Sleep for one millisecond */
}
Looks like linux doesnt implement pthread_suspend and continue, but I really need em.
I have tried cond_wait, but it is too slow. The work being threaded mostly executes in 50us but occasionally executes upwards of 500ms. The problem with cond_wait is two-fold. The mutex locking is taking comparable times to the micro second executions and I don't need locking. Second, I have many worker threads and I don't really want to make N condition variables when they need to be woken up.
I know exactly which thread is waiting for which work and could just pthread_continue that thread. A thread knows when there is no more work and can easily pthread_suspend itself. This would use no locking, avoid the stampede, and be faster. Problem is....no pthread_suspend or _continue.
Any ideas?
Make the thread wait for a specific signal.
Use pthread_sigmask and sigwait.
Have the threads block on a pipe read. Then dispatch the data through the pipe. The threads will awaken as a result of the arrival of the data they need to process. If the data is very large, just send a pointer through the pipe.
If specific data needs to go to specific threads you need one pipe per thread. If any thread can process any data, then all threads can block on the same pipe and they will awaken round robin.
It seems to me that such a solution (that is, using "pthread_suspend" and "pthread_continue") is inevitably racy.
An arbitrary amount of time can elapse between the worker thread finishing work and deciding to suspend itself, and the suspend actually happening. If the main thread decides during that time that that worker thread should be working again, the "continue" will have no effect and the worker thread will suspend itself regardless.
(Note that this doesn't apply to methods of suspending that allow the "continue" to be queued, like the sigwait() and read() methods mentioned in other answers).
May be try an option of pthread_cancel but be careful if any locks to be released,Read the man page to identify cancel state
Why do you care which thread does the work? It sounds like you designed yourself into a corner and now you need a trick to get yourself out of it. If you let whatever thread happened to already be running do the work, you wouldn't need this trick, and you would need fewer context switches as well.