I am working on creating a threadpool from scratch as part of an assignment and am able to create the thread pool and then pass each created thread a function that constantly loops. My question is how can I accept the input and pass it to an already executing pthread. After figuring this out I will add mutexes to lock the function to a specific thread, but I am unable to get to that part.
class ThreadPool{
public:
ThreadPool(size_t threadCount);
int dispatch_thread(void *(dispatch_function(void *)), void *arg);
bool thread_avail();
int numThreads;
pthread_t * thread;
pthread_mutex_t * mutexes;
};
int ThreadPool::dispatch_thread(void *(dispatch_function(void *)), void *arg){
flag = 1;
//This is where I would like to pass the function the running pthread
}
void *BusyWork(void *t)
{
while(true){
//This is where I would like to run the passed function from each thread
//I can run the passed function by itself, but need to pass it to the threadpool
}
}
ThreadPool::ThreadPool(size_t threadCount){
pthread_t thread[threadCount];
for(t=0; t<threadCount; t++) {
//printf("Main: creating thread %ld\n", t);
rc = pthread_create(&thread[t], NULL, BusyWork, (void *)t);
}
}
void *test_fn(void *par)
{
cout << "in test_fn " << *(int *)par << endl;
}
int main (){
ThreadPool th(3);
int max = 100;
for (int i = 0; i < 20; i++) {
max = 100 * i;
th.dispatch_thread(test_fn, (void *)&max);
sleep(1);
}
}
The best pattern that I can think of is to use some sort of queue to pass messages to the thread-pool. These messages may contain functions to be run as well as some control messages for shutting down the thread-pool. As you already have guessed, the queue will have to be thread safe.
A simple approach for the queue is to use a fixed size array which you turn into a circular buffer. The array will have a Mutex to lock it when accessing the array and a Condition Variable to awaken the thread-pool thread.
When putting an item on the queue, we lock the mutex, add to the queue and then signal the thread-pool with the Condition Variable.
Each running thread in the in the thread pool will start life by locking the mutex and waiting on the condition varaible (which automaticall unlocks the Mutex). When awoken it will remove the item from the queue, and then unlock the mutex. It is now free do its stuff. When finished it goes to sleep until re-signaled.
As general advice, avoid sharing memory between threads because this either leads to race conditions (if access is not protected) or leads to interlocking (if access is locked). Also avoid locking a mutex when performing any long running operation such as calling new (malloc), delete (free) or any system calls.
Related
I want to make function that when receive buffer from socket, thread make whole program freeze out of my function until my function is finished. I try these as below
Function Listen
void Listen(can* _c) {
while (true)
{
std::lock_guard<std::mutex>guard(_c->connection->mutex);
thread t(&connect_tcp::Recv_data,_c->connection,_c->s,ref(_c->response),_c->signals);
if (t.joinable())
t.join();
}
}
Function dataset_browseCan
void dataset_browseCan(can* _c) {
thread org_th(Listen, _c); // I call thread here
org_th.detach();
dataset_browse(_c->cotp, _c->mms_obj, _c->connection, _c->response, _c->list, _c->size_encoder, _c->s);
dataset_signals_browse(_c->cotp, _c->mms_obj, _c->connection, _c->response, _c->list, _c->size_encoder, _c->s);
Sleep(800);
_c->signals = new Signals[_c->response.real_signals_and_values.size()];
}
Function Recv Data
void connect_tcp::Recv_data(SOCKET s,mms_response &response,Signals *signals) {
LinkedList** list = new LinkedList * [1000];
uint8_t* buffer = new uint8_t [10000];
Sleep(800);
/*std::lock_guard<std::mutex>guard(mutex);*/
thread j(recv,s, (char*)buffer, 10000, 0);
j.join()
/*this->mutex.unlock();*/
decode_bytes(response,buffer, list,signals);
}
I tried mutex and this_thread::sleep_for() but everytime my main function keep running.
Is make program freeze possible ?
You use threads in order to allow things to keep running while something else is happening, so wanting to "stop main" seems counter-intuitive.
However, if you want to share data between threads (e.g. between the thread that runs main and a background thread) then you need to use some form of synchronization. One way to do that is to use a std::mutex. If you lock the mutex before every access, and unlock it afterwards (using std::lock_guard or std::unique_lock) then it will prevent another thread from locking the same mutex while you are accessing the data.
If you need to prevent concurrent access for a long time, then you should not hold a mutex for the whole time. Either consider whether threads are the best solution to your problem, or use a mutex-protected flag to indicate whether the data is ready, and then either poll or use std::condition_variable or similar to wait until the flag is set.
I have a function like following in which threads acquire a lock by using std::lock_guard mutex and write to the file via ofstream.
When the current file size increases the max size, then I want to create an independent thread that should compress the file and should terminate.
I want to understand the implications of calling pthread_create when std::lock_guard is still in scope.
Is it safe? Will the lock be applied to the new thread (I don't intend it to be so) as well?
void log (std::string message)
{
std::lock_guard<std::mutex> lck(mtx);
_outputFile << message << std::endl;
_outputFile.flush();
_sequence_number++;
_curr_file_size = _outputFile.tellp();
if (_curr_file_size >= max_size) {
char *lf = strdup(_logfile.c_str());
// Create an independent thread to compress the file since
// it takes some time to compress huge files.
if (!_compress_thread) {
pthread_create(&_compress_thread, NULL, compress_log, (void *)lf);
}
}
}
void * compress_log (void *arg)
{
pthread_detach(pthread_self());
// Code to compress the file
// ...
{ // Create a scope for lock_gaurd
std::lock_guard<std::mutex> lck(mtx);
_compress_thread = NULL;
}
pthread_exit(NULL);
}
A mutex works at thread level, it only affects the thread that uses it. When a thread locks a mutex, two things can happen:
A mutex is unlocked - it becomes locked and the thread execution continues.
A mutex is already locked - the thread does not continue, but waits until the mutex becomes unlocked.
Your new thread runs the compress_log() function, which does not access the mutex at all. Consequently, it will run regardless of whether the mutex is locked or not (the mutex in your case will unlock when log() exits).
An unrelated advise: use std::thread instead of pthread_create, this way your application becomes more portable:
std::thread{ [lf] { compress_log(lf); } }.detach();
So, I'm writing a sort of oscilloscope-esque program that reads the the serial port on the computer and performs an fft on this data to convert it to the frequency spectrum. I ran into an issue though with the layout of my program which is broken up into a SerialHandler class (utilizing boost::Asio), an FFTHandler class, and a main function. The SerialHandler class uses the boost::Asio`` async_read_some function to read from the port and raise an event called HandleOnPortReceive which then reads the data itself.
The issue was that I couldn't find a way to pass that data from the event handler, being raised by an io_service object on another thread, to the FFTHandler class, which is on yet another thread. I was recommended to use semaphores to solve my problem, but I have next to no knowledge on semaphore.h usage, so my implementation is now rather broken and doesn't do much of anything it's supposed to.
Here's some code if that makes it a little clearer:
using namespace Foo;
//main function
int main(void){
SerialHandler serialHandler;
FFTHandler fftHandler;
sem_t *qSem_ptr = &qSem;
sem_init(qSem_ptr, 1, 0);
//create separate threads for both the io_service and the AppendIn so that neither will block the user input statement following
serialHandler.StartConnection(tempInt, tempString); //these args are defined, but for brevity's sake, I ommitted the declaration
t2= new boost::thread(boost::bind(&FFTHandler::AppendIn, &fftHandler, q, qSem));
//allow the user to stop the program and avoid the problem of an infinite loop blocking the program
char inChar = getchar();
if (inChar) {...some logic to stop reading}
}
namespace Foo{
boost::thread *t1;
boost::thread *t2;
sem_t qSem;
std::queue<double> q;
boost::mutex mutex_;
class SerialHandler{
private:
char *rawBuffer; //array to hold incoming data
boost::asio::io_service ioService;
boost::asio::serial_port_ptr serialPort;
public:
void SerialHandler::StartConnection(int _baudRate, string _comPort){
//some functionality to open the port that is irrelevant to the question goes here
AsyncReadSome(); //starts the read loop
//create thread for io_service object and let function go out of scope
t1 = new boost::thread(boost::bind(&boost::asio::io_service::run, &ioService));
}
void SerialHandler::AsyncReadSome(){
//there's some other stuff here for error_catching, but this is the only important part
serialPort->async_read_some (
boost::asio::buffer(rawBuffer, SERIAL_PORT_READ_BUF_SIZE),
boost::bind(
&SerialHandler::HandlePortOnReceive,
this, boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred, q));
}
void SerialHandler::HandlePortOnReceive(const boost::system::error_code& error, size_t bytes_transferred, std::queue<double>& q){
boost::mutex::scoped_lock lock(mutex_);
//more error checking goes here, but I've made sure they aren't returning and are not the issue
for (unsigned int i =0; i<bytes_transferred; i++){
unsigned char c = rawBuffer[i];
double d = (double) c; //loop through buffer and read
if (c==endOfLineChar){
} else //if not delimiting char, push into queue and post semaphore
{
q.push(d);
//cout << d << endl;
sem_post(&qSem);
cout << q.front() << endl;
cout << "size is: " << q.size() << endl;
}
}
//loop back on itself and start the next read
AsyncReadSome();
}
}
class FFTHandler{
private:
double *in; //array to hold inputs
fftw_complex *out; //holds outputs
int currentIndex;
bool filled;
const int N;
public:
void AppendIn(std::queue<double> &q, sem_t &qSem){
while(1){ //this is supposed to stop thread from exiting and going out of scope...it doesn't do that at all effectively...
cout << "test" << endl;
sem_wait(&_qSem); //wait for data...this is blocking but I don't know why
double d = _q.front();
_q.pop();
in[currentIndex]=d; //read queue, pop, then append in array
currentIndex++;
if (currentIndex == N){ //run FFT if full and reset index
currentIndex = N-overlap-1;
filled = true;
RunFFT();
}
}
}
}
}
That debug line in FFTHandler::AppendIn(..) is indeed firing, so the thread is being created, but it's immediateley going out of scope it seems and destructing the thread, because it seems I've set up the while to respond incorrectly to the semaphore.
TLDR: That was a long explanation to simply say, "I don't understand semaphores but need to somehow implement them. I tried, failed, so now I'm coming here to hopefully receive help on this code from somebody more knowledgeable than me.
UPDATE: So after playing around with some debug statements, it seems that the issue is that the while(1){...} statement is indeed firing, but, the sem_wait(&_qSem); is causing it to block. For whatever reason it is waiting indefinitely and despite the fact that the semaphore is being posted, it continues to wait and never progress beyond that line.
Since you're already using boost::mutex and its scoped lock type, I suggest you use boost::condition_variable instead of a POSIX semaphore. Otherwise you're mixing C++11-style synchronisation with POSIX synchronisation.
You lock the mutex when adding to the queue, but I don't see anything locking the mutex to read from the queue. It also looks like you're looping back to call AsyncReadSome while the mutex is still locked.
Pick a single form of synchronisation, and then use it correctly.
The initial value of the semaphore is 0 which is valid for this case. So it needs a sem_post for FFTHandler::AppendIn() to be unblocked. But I dont see the code that invokes SerialHandler::AsyncReadSome() for the first time for the serial port to be read and the push to happen into the queue. If you fix that part of the code, I think sem_post would happen and the FFTHandler thread would run. As the first step you can have debug prints one after the sem_wait and one inside AsyncReadSome() function, and my guess is that both wont get executed.
So, essentially you would want to ensure that 'reading' gets initiated and is kept alive as part of the main thread or a different thread.
Suppose we have two workers. Each worker has an id of 0 and 1. Also suppose that we have jobs arriving all the time, each job has also an identifier 0 or 1 which specifies which worker will have to do this job.
I would like to create 2 threads that are initially locked, and then when two jobs arrive, unlock them, each of them does their job and then lock them again until other jobs arrive.
I have the following code:
#include <iostream>
#include <thread>
#include <mutex>
using namespace std;
struct job{
thread jobThread;
mutex jobMutex;
};
job jobs[2];
void executeJob(int worker){
while(true){
jobs[worker].jobMutex.lock();
//do some job
}
}
void initialize(){
int i;
for(i=0;i<2;i++){
jobs[i].jobThread = thread(executeJob, i);
}
}
int main(void){
//initialization
initialize();
int buffer[2];
int bufferSize = 0;
while(true){
//jobs arrive here constantly,
//once the buffer becomes full,
//we unlock the threads(workers) and they start working
bufferSize = 2;
if(bufferSize == 2){
for(int i = 0; i<2; i++){
jobs[i].jobMutex.unlock();
}
}
break;
}
}
I started using std::thread a few days ago and I'm not sure why but Visual Studio gives me an error saying abort() has been called. I believe there's something missing however due to my ignorance I can't figure out what.
I would expect this piece of code to actually
Initialize the two threads and then lock them
Inside the main function unlock the two threads, the two threads will do their job(in this case nothing) and then they will become locked again.
But it gives me an error instead. What am I doing wrong?
Thank you in advance!
For this purpose you can use boost's threadpool class.
It's efficient and well tested. opensource library instead of you writing newly and stabilizing it.
http://threadpool.sourceforge.net/
main()
{
pool tp(2); //number of worker threads-currently its 2.
// Add some tasks to the pool.
tp.schedule(&first_task);
tp.schedule(&second_task);
}
void first_task()
{
...
}
void second_task()
{
...
}
Note:
Suggestion for your example:
You don't need to have individual mutex object for each thread. Single mutex object lock itself will does the synchronization between all the threads. You are locking mutex of one thread in executejob function and without unlocking another thread is calling lock with different mutex object leading to deadlock or undefined behaviour.
Also since you are calling mutex.lock() inside whileloop without unlocking , same thread is trying to lock itself with same mutex object infinately leading to undefined behaviour.
If you donot need to execute threads parallel you can have one global mutex object can be used inside executejob function to lock and unlock.
mutex m;
void executeJob(int worker)
{
m.lock();
//do some job
m.unlock();
}
If you want to execute job parallel use boost threadpool as I suggested earlier.
In general you can write an algorithm similar to the following. It works with pthreads. I'm sure it would work with c++ threads as well.
create threads and make them wait on a condition variable, e.g. work_exists.
When work arrives you notify all threads that are waiting on that condition variable. Then in the main thread you start waiting on another condition variable work_done
Upon receiving work_exists notification, worker threads wake up, and grab their assigned work from jobs[worker], they execute it, they send a notification on work_done variable, and then go back to waiting on the work_exists condition variable
When main thread receives work_done notification it checks if all threads are done. If not, it keeps waiting till the notification from last-finishing thread arrives.
From cppreference's page on std::mutex::unlock:
The mutex must be unlocked by all threads that have successfully locked it before being destroyed. Otherwise, the behavior is undefined.
Your approach of having one thread unlock a mutex on behalf of another thread is incorrect.
The behavior you're attempting would normally be done using std::condition_variable. There are examples if you look at the links to the member functions.
Let say I have an array of 5 threads :
//main thread
pthread_t t[5];
pthread_mutex_t mutex[5];
queue<int> q[5];
for(int i = 0; i < 5; i++){
pthread_create(&pthread_t[i], NULL, worker, NULL);
}
for(int i = 0; i < 5; i++){
pthread_mutex_lock(&mutex[i]);
queue[i].push_back(i);
pthread_mutex_unlock(&mutex[i]);
}
void* worker(void* arg){
pthread_mutex_lock(&mutex[?]);
}
I am confused with the mutex_lock here. My question is:
How could I let the worker know which mutex to lock?
When I access the mutex through mutex[i], do I need another lock since the child thread might be accessing the mutex array as well?
Thanks.
You need to be clear which threads are sharing which queues. The code you've written suggests each worker thread works on a specific queue, but the main thread (that spawns the workers) will be pushing back new values onto those queues. If that's what you want, then what you've done is basically correct, and you can let the worker threads know the array index of the mutex they're to lock/unlock by casting it to void* and passing it as the argument to pthread_create, which will in turn be passed as a void* to the worker function. You do not need any additional layer of locking around the mutex array - it is entirely safe to access specific elements independently, though if it were say a vector that was being resized at run-time, then you would need that extra level of locking.
Associate the mutex with the queue creating a new struct;
typedef struct {
pthread_mutex_t mutex;
queue<int> q;
} safe_queue;
safe_queue queue_pool [5];
void* worker(safe_queue){
pthread_mutex_lock(&safe_queue.mutex);
}
That last argument to the pthread_create is handed over to the thread when it's called, so you can just pass a value to the specific thread.
Since you want both a specific mutex and a specific queue, you're better off passing in the value of i directly.
for(int i = 0; i < 5; i++){
pthread_create(&pthread_t[i], NULL, worker, (void*)i);
}
void *worker (void *pvI) {
int idx = (int)pvI; // Check for cast problems.
// Use mutex[idx] and q[idx].
}
However, if you want to do it this way, I'd go for a single queue and mutex.
That's because the act of putting something on the queue is almost certainly going to be much faster than processing an item on the queue (otherwise you wouldn't need threads at all).
If you have multiple queues, the main thread has to figure out somehow which are the underutilised threads so it can select the best queue. If you have one queue and one mutex to protect it, the threads will self-organise for efficiency. Those threads that do long jobs won't try to get something from the queue. Those doing short jobs will come back sooner.
I should mention that mutexes on their own are not a good solution for this producer/consumer model. You can't have a thread lock the mutex then wait indefinitely on the queue since that will prevent the main thread putting anything on the queue.
So that means your worker threads will be constantly polling the queues looking for work.
If you use a mutex combined with a condition variable, it will be a lot more efficient. That's because the threads are signalled by the main thread when work is available rather than constantly grabbing the mutex, checking for work, then releasing the mutex.
The basic outline will be, for the main thread:
initialise
while not finished:
await work
lock mutex
put work on queue
signal condvar
unlock mutex
terminate
and, for the worker threads:
initialise
while not finished:
lock mutex
while queue is empty:
wait on condvar
get work from queue
unlock mutex
do work
terminate
Don't pass a NULL pointer as arg to the thread. Instead use a pointer to an object that defines what the thread has to do.
How could I let the worker know which mutex to lock?
Pass the number as the last parameter to pthread_create()
for(int i = 0; i < 5; i++)
{
pthread_create(&pthread_t[i], NULL, worker, reinterpret_cast<void*>(i));
}
Then you can get the value like this:
void* worker(void* arg)
{
int index = reinterpret_cast<int>(arg);
pthread_mutex_lock(&mutex[index]);
}
When I access the mutex through mutex[i], do I need another lock since the child thread might be accessing the mutex array as well?
No. Because the variable mutex itself is never modified. Each member of the array behaves in an atomic fashion via the pthread_mutext_X() methods.
A slightly better design would be:
//main thread
struct ThreadData
{
pthread_mutex_t mutex;
queue<int> queue;
};
pthread_t t[5];
ThreadData d[5];
for(int i = 0; i < 5; i++)
{
pthread_create(&t[i], NULL, worker, &d[i]); // Pass a pointer to ThreadData
}
void* worker(void* arg)
{
// Retrieve the ThreadData object.
ThreadData d = reinterpret_cast<ThreadData*>(arg);
pthread_mutex_lock(&(d.mutex));
<STUFF>
}