I need to spawn a thread when a certain trigger event is received inside of a class Foo. The trigger event is received by a Winsock server class that has a reference to the variable triggerEvent.
bool Foo::HandleEvents()
{
while (1)
{
// Other things are done at the top of this loop
switch (triggerEvent)
{
case 'h':
{
// I instantiate an object here to do
// what I need to do in the thread.
// I use a pointer that is a private
// member of Foo.
thingMaker = new ThingMaker(params);
// Spawn a new thread here calling a
// function of ThingMaker and using thingMaker
break;
}
case ...: return true;
default: break;
}
}
}
Since the thread is local to its case in the switch, I lose access to it on break. I can't call join() because I'm dealing with real-time processing and cannot wait for the thread to finish unless I know it's already done.
I recently asked a question about threading here regarding the same application and was told detach() is bad practice; I also think my question was too vague as the solution offered ended up not fitting my needs and my application has since changed in architecture.
I have also tried to encapsulate the thread in short-life manager class that creates instances of ThingMaker but to no avail.
How do I go about this? I suspect my main issue is scope, but my options are limited. Foo::HandleEvents() cannot be delayed at all or else I lose critical data.
You could use a std::map (or one of the other similar containers):
class Foo
{
bool HandleEvents();
std::map<ThingMaker*, std::thread> m_map;
};
bool Foo::HandleEvents()
{
while (1)
{
switch (triggerEvent)
{
case 'h':
{
thingMaker = new ThingMaker(params);
m_map[thingMaker] = std::thread(function_ptr, thingMaker);
} break;
case 't': // termination event trigger
{
m_map[thingMaker].second.join();
m_map.erase(thingMaker);
delete thingMaker;
} break;
case ...: return true;
default: break;
}
}
}
Since this obviously isn't your full code you'd have to adjust the above code to fit your needs, but you could swap the map's key/value in the template, or use the thread ID instead if that would make more sense (e.g. std::map<std::thread::id, ThingMaker*>, etc.), but something like a map avoids iterating over an array and joining on each thread or having to implement a full thread pool implementation if you don't necessarily need one.
Side note: the use of detach is not bad, in fact it's quite useful; detaching a thread signals to the kernel that the thread can be "cleaned up" as soon as it's done executing (which releases certain resources and handles). Calling detach on a thread is useful when you know you will no longer need access to the underlying thread handle (like in an extremely short lived thread). It's neither bad nor good, simply a tool to utilize (like the infamous goto statement).
Hope that can help.
Related
I have this class Foo, such that when you create an instance of it, it starts a background thread in the constructor, and the background thread runs until the destructor is called on the object instance (which sets a flag to tell the background thread to exit) and then waits for the background thread finishes.
So, I want to write a small program that runs the background thread indefinitely
int main(int argc, char[][] argv)
{
Foo foo(argc, argv);
block_forever(); // How do I implement this portably?
return 0;
}
making something like ctrl-c/a signal to cause block_forever to return would be a nice bonus (but in general I can just kill the process)
Foo can be modeled as
class Foo
{
public:
Foo() : m_stopFlag(false)
{
m_thread = StartThread(&ThreadFn, this);
if (!m_thread) throw ...;
}
~Foo()
{
m_stopFlag = true;
JoinThread(m_thread);
}
private:
void* ThreadFn(void* threadParam)
{
Foo& foo(*static_cast<Foo*>(threadParam);
try
{
while (!foo.m_stopFlag)
{
DoSomethingInteresting();
SleepFiveSeconds();
}
return NULL;
}
catch (...)
{
abort();
}
}
volatile bool m_stopFlag;
THREAD_HANDLE m_thread;
};
So, the Foo background thread will never exit on it's own. It can only be stopped by the Foo instance destructor modifying m_stopFlag, and if anything goes wrong, any resulting exception will cause the process to abort.
I want to write a version of main() like the one above which will never (or at least not until something like a signal) reach the end of main(), and thus end my Foo background thread.
Foo is under my control, but I would rather not change it unless it was necessary.
Likely a while loop around a wait on a condition variable is what you are looking for. The condition variable is never signalled. You still need the while loop because of spurious lookups and you need a vestigial mutex. As a bonus, when you do need to break out of the wait loop, it will be obvious how to do so. Waiting on a semaphore will also work if that abstraction is available.
That said, in any real situation, there are complications. First off, The thread abstraction may or may not be within your definition of "portable." Second, in some environments a main thread has responsibilities such as running an event loop. So this will not be entirely portable. On POSIX based systems I might just use sigwait.
I'm just getting into concurrent programming. Most probably my issue is very common, but since I can't find a good name for it, I can't google it.
I have a C++ UWP application where I try to apply MVVM pattern, but I guess that the pattern or even being UWP is not relevant.
First, I have a service interface that exposes an operation:
struct IService
{
virtual task<int> Operation() = 0;
};
Of course, I provide a concrete implementation, but it is not relevant for this discussion. The operation is potentially long-running: it makes an HTTP request.
Then I have a class that uses the service (again, irrelevant details omitted):
class ViewModel
{
unique_ptr<IService> service;
public:
task<void> Refresh();
};
I use coroutines:
task<void> ViewModel::Refresh()
{
auto result = co_await service->Operation();
// use result to update UI
}
The Refresh function is invoked on timer every minute, or in response to a user request. What I want is: if a Refresh operation is already in progress when a new one is started or requested, then abandon the second one and just wait for the first one to finish (or time out). In other words, I don't want to queue all the calls to Refresh - if a call is already in progress, I prefer to skip a call until the next timer tick.
My attempt (probably very naive) was:
mutex refresh;
task<void> ViewModel::Refresh()
{
unique_lock<mutex> lock(refresh, try_to_lock);
if (!lock)
{
// lock.release(); commented out as harmless but useless => irrelevant
co_return;
}
auto result = co_await service->Operation();
// use result to update UI
}
Edit after the original post: I commented out the line in the code snippet above, as it makes no difference. The issue is still the same.
But of course an assertion fails: unlock of unowned mutex. I guess that the problem is the unlock of mutex by unique_lock destructor, which happens in the continuation of the coroutine and on a different thread (other than the one it was originally locked on).
Using Visual C++ 2017.
use std::atomic_bool:
std::atomic_bool isRunning = false;
if (isRunning.exchange(true, std::memory_order_acq_rel) == false){
try{
auto result = co_await Refresh();
isRunning.store(false, std::memory_order_release);
//use result
}
catch(...){
isRunning.store(false, std::memory_order_release);
throw;
}
}
Two possible improvements : wrap isRunning.store in a RAII class and use std::shared_ptr<std::atomic_bool> if the lifetime if the atomic_bool is scoped.
I have the following manager<->worker situation:
class Manager {
private:
pthread_attr_t workerSettings;
pthread_t worker;
pthread_cond_t condition;
pthread_mutex_t mutex;
bool workerRunning;
static void* worker_function(void* args) {
Manager* manager = (Manager*)args;
while(true) {
while(true) {
pthread_mutex_lock(&manager->mutex);
if(/* new data available */)
{
/* copy new data from shared to thread memory */
pthread_mutex_unlock(&manager->mutex);
}
else
{
pthread_mutex_unlock(&manager->mutex);
break;
}
/* process the data in thread memory */
pthread_mutex_lock(&manager->mutex);
/* copy results back to shared memory */
pthread_mutex_unlock(&manager->mutex);
}
pthread_mutex_lock(&manager->mutex);
// wait for new data to arrive
while(manager->workerRunning && !/* new data available*/)
pthread_cond_wait(&manager->condition, &manager->mutex);
// check if we should continue running
if(!manager->workerRunning)
{
pthread_mutex_unlock(&manager->mutex);
break;
}
pthread_mutex_unlock(&manager->mutex);
}
pthread_exit(NULL);
return NULL; // just to avoid the missing return statement compiler warning
}
public:
Manager() : workerRunning(true) {
pthread_cond_init(&condition, NULL);
pthread_mutex_init(&mutex, NULL);
pthread_attr_init(&workerSettings);
pthread_attr_setdetachstate(&workerSettings, PTHREAD_CREATE_JOINABLE);
pthread_create(&worker, &workerSettings, worker_function, (void*)this);
}
// this *may* be called repeatedly or very seldom
void addData(void) {
pthread_mutex_lock(&mutex);
/* copy new data into shared memory */
pthread_cond_signal(&condition);
pthread_mutex_unlock(&mutex);
}
~Manager()
{
// set workerRunning to false and signal the worker
pthread_mutex_lock(&mutex);
workerRunning = false;
pthread_cond_signal(&condition);
pthread_mutex_unlock(&mutex);
// wait for the worker to exit
pthread_join(worker, NULL);
// cleanup
pthread_attr_destroy(&workerSettings);
pthread_mutex_destroy(&mutex);
pthread_cond_destroy(&condition);
}
};
I'm not completely sure about this at several places:
Is the fact that Manager spawns a new thread in its constructor considered a bad practice? (I will only have one Manager object, so i guess that should be fine)
What about the pthread_exit - i see this in many tutorials but i don't quite get why it should be there? Can't i simply return the function to exit the thread? I also think the return NULL is dead code, but gcc warns when it's missing because it obviously can't know that pthread_exit already killed the thread at that point.
About the constructor - can i destroy the thread attr object (workerSettings) immediately after spawning the thread or does it have to stay valid for the entire lifetime of the thread?
About the destructor: Is this the right way to do this?
And most importantly:
Do your experienced eyes see any synchronization issues there?
Thanks for your help!
You ask...
Is the fact that Manager spawns a new thread in its constructor considered a bad practice?
In most cases, RAII is good enough to approach the object creation and resource acquisition. In some cases you may want to achieve the deferred resource initialization: when you first construct an object and later you proceed with the initialization. This can be achieved, for example, via a ctor (either default or parameterized) and open/start routines. Though you may also do it in the ctor and achieve the deffered object creation by allocating the object in the process heap (via operator new). It depends on your requirements, software design considerations and corporate software development standards.
So, you may create a thread in ctor, or may want or need to spawn it in the later stage of the application/object lifecycle.
What about the pthread_exit
It is not required. It terminates the calling thread, making its exit status available to any waiting threads (i.e. via pthread_join()). An implicit call to pthread_exit() occurs when any thread returns from its start routine. Basically, the pthread_exit() function provides an interface similar to exit() but on a per-thread basis (including cancelation cleanup handlers). But beware of calling pthread_exit() from cancelation cleanup handlers or from destructors of objects allocated in the TSD (thread-specific data area) - it can lead to undesirable side effects.
About the constructor - can i destroy the thread attr object (workerSettings) immediately after spawning the thread or does it have to stay valid for the entire lifetime of the thread?
Yes, you can destroy it right away: it will not affect already created threads.
About the destructor: Is this the right way to do this?
Same thing as for ctor: you may use dtor and close/stop routine or can do it all in the dtor: depends on your specific needs (e.g. object reusability etc). Just make the dtor not throw.
Do your experienced eyes see any synchronization issues there?
I may suggest using pthread_testcancel(), to introduce the explicit cancelation point in a thread, and issue pthread_cancel() + pthread_join() (should return PTHREAD_CANCELED) in the control thread to stop the child thread, instead of synch variable workerRunning. Of course, if it is applicable in your case.
You should check for new data as soon as pthread_cond_wait returns, and wait again if there's no new data. That can happen if you get a spurious wake (think of it as the kernel accidentally waking you up by dropping something heavy down the stairs), and it would be better to wait immediately instead of changing workerWaiting then unlocking and relocking the mutex twice before waiting again.
An RAII lock type would make the code so much cleaner:
while(true) {
while(true) {
{
scoped_lock l(&manager->mutex);
if(/* new data available */)
{
/* copy new data from shared to thread memory */
}
else
break;
}
/* process the data in thread memory */
scoped_lock l(&manager->mutex);
/* copy results back to shared memory */
}
scoped_lock l(&manager->mutex);
// check if we should continue running
if(!manager->workerRunning)
break;
// wait for new data to arrive
manager->workerWaiting = true;
while (!/* new data available */)
pthread_cond_wait(&manager->condition, &manager->mutex);
manager->workerWaiting = false;
}
Using pthread_cancel as Oleg suggests would simplify it even further.
Following your edit to the code to handle spurious wake-ups, it becomes much simpler if you use RAII and restructure it:
while(true)
{
{
scoped_lock l(&manager->mutex);
// wait for new data to arrive
while(manager->workerRunning && !/* new data available*/)
pthread_cond_wait(&manager->condition, &manager->mutex);
// check if we should continue running
if(!manager->workerRunning)
break;
/* copy new data from shared to thread memory */
}
/* process the data in thread memory */
scoped_lock l(&manager->mutex);
/* copy results back to shared memory */
}
return NULL;
Without something like scoped_lock, what happens if /* copy new data from shared to thread memory */ or /* process the data in thread memory */ throws an exception? You'll never unlock the mutex.
The RAII type could be as simple as:
struct scoped_lock {
explicit scoped_lock(pthrad_mutex_t* m) : mx(m) {
pthread_mutex_lock(mx);
}
~scoped_lock() { pthread_mutex_unlock(mx); }
private:
pthread_mutex_t* mx;
scoped_lock(const scoped_lock&);
scoped_lock operator=(const scoped_lock&);
};
I'm a bit stumped on an issue I'm having with threading and C++. I'm writing a DSP plugin for Windows Media Player, and I want to send the data I intercept to a separate thread where I'll send it out on the network. I'm using a simple producer-consumer queue like the one explained here
The program is crashing on the isFull() function which just compares two integers:
bool ThreadSafeQueue::isFull()
{
if (inCount == outCount) //CRASH!
return true;
else
return false;
}
The thread that's doing the dequeuing:
void WMPPlugin::NetworkThread (LPVOID pParam)
{
ThreadSafeQueue* dataQueue = (ThreadSafeQueue*)(pParam);
while (!networkThreadDone)
{
Sleep(2); /// so we don't hog the processor or make a race condition
if (!dataQueue->isFull())
short s = dataQueue->dequeue();
if (networkThreadDone) // variable set in another process so we know to exit
break;
}
}
The constructor of the class that's creating the consumer thread:
WMPPlugin::WMPPlugin()
{
// etc etc
dataQueue = new ThreadSafeQueue();
_beginthread(WMPPlugin::NetworkThread, 0, dataQueue);
}
inCount and outCount are just integers and they're only read here, not written. I was under the impression this meant they were thread safe. The part that writes them aren't included, but each variable is only written to by one thread, never by both. I've done my best to not include code that I don't feel is the issue, but I can include more if necessary. Thanks in advance for any help.
Most often, when a crash happens accessing a normal member variable, it means this is NULL or an invalid address.
Are you sure you aren't invoking it on a NULL instance?
Regarding this line:
ThreadSafeQueue* dataQueue = (ThreadSafeQueue*)(pParam);
How sure are you that pParam is always non-NULL?
How sure are you that pParam is always a ThreadSafeQueue object?
Are you possible deleting the ThreadSafeQueue objects on other threads?
I have an object that is called from two different threads and after it was called by both it destroys itself by "delete this".
How do I implement this thread-safe? Thread-safe means that the object never destroys itself exactly one time (it must destroys itself after the second callback).
I created some example code:
class IThreadCallBack
{
virtual void CallBack(int) = 0;
};
class M: public IThreadCallBack
{
private:
bool t1_finished, t2_finished;
public:
M(): t1_finished(false), t2_finished(false)
{
startMyThread(this, 1);
startMyThread(this, 2);
}
void CallBack(int id)
{
if (id == 1)
{
t1_finished = true;
}
else
{
t2_finished = true;
}
if (t1_finished && t2_finished)
{
delete this;
}
}
};
int main(int argc, char **argv) {
M* MObj = new M();
while(true);
}
Obviously I can't use a Mutex as member of the object and lock the delete, because this would also delete the Mutex. On the other hand, if I set a "toBeDeleted"-flag inside a mutex-protected area, where the finised-flag is set, I feel unsure if there are situations possible where the object isnt deleted at all.
Note that the thread-implementation makes sure that the callback method is called exactly one time per thread in any case.
Edit / Update:
What if I change Callback(..) to:
void CallBack(int id)
{
mMutex.Obtain()
if (id == 1)
{
t1_finished = true;
}
else
{
t2_finished = true;
}
bool both_finished = (t1_finished && t2_finished);
mMutex.Release();
if (both_finished)
{
delete this;
}
}
Can this considered to be safe? (with mMutex being a member of the m class?)
I think it is, if I don't access any member after releasing the mutex?!
Use Boost's Smart Pointer. It handles this automatically; your object won't have to delete itself, and it is thread safe.
Edit:
From the code you've posted above, I can't really say, need more info. But you could do it like this: each thread has a shared_ptr object and when the callback is called, you call shared_ptr::reset(). The last reset will delete M. Each shared_ptr could be stored with thread local storeage in each thread. So in essence, each thread is responsible for its own shared_ptr.
Instead of using two separate flags, you could consider setting a counter to the number of threads that you're waiting on and then using interlocked decrement.
Then you can be 100% sure that when the thread counter reaches 0, you're done and should clean up.
For more info on interlocked decrement on Windows, on Linux, and on Mac.
I once implemented something like this that avoided the ickiness and confusion of delete this entirely, by operating in the following way:
Start a thread that is responsible for deleting these sorts of shared objects, which waits on a condition
When the shared object is no longer being used, instead of deleting itself, have it insert itself into a thread-safe queue and signal the condition that the deleter thread is waiting on
When the deleter thread wakes up, it deletes everything in the queue
If your program has an event loop, you can avoid the creation of a separate thread for this by creating an event type that means "delete unused shared objects" and have some persistent object respond to this event in the same way that the deleter thread would in the above example.
I can't imagine that this is possible, especially within the class itself. The problem is two fold:
1) There's no way to notify the outside world not to call the object so the outside world has to be responsible for setting the pointer to 0 after calling "CallBack" iff the pointer was deleted.
2) Once two threads enter this function you are, and forgive my french, absolutely fucked. Calling a function on a deleted object is UB, just imagine what deleting an object while someone is in it results in.
I've never seen "delete this" as anything but an abomination. Doesn't mean it isn't sometimes, on VERY rare conditions, necessary. Problem is that people do it way too much and don't think about the consequences of such a design.
I don't think "to be deleted" is going to work well. It might work for two threads, but what about three? You can't protect the part of code that calls delete because you're deleting the protection (as you state) and because of the UB you'll inevitably cause. So the first goes through, sets the flag and aborts....which of the rest is going to call delete on the way out?
The more robust implementation would be to implement reference counting. For each thread you start, increase a counter; for each callback call decrease the counter and if the counter has reached zero, delete the object. You can lock the counter access, or you could use the Interlocked class to protect the counter access, though in that case you need to be careful with potential race between the first thread finishing and the second starting.
Update: And of course, I completely ignored the fact that this is C++. :-) You should use InterlockExchange to update the counter instead of the C# Interlocked class.