Linux is a new platform to me. I've coded on Windows in c++ for a number of years and have become comfortable with multithreading on that platform.
Along comes C++11 at a time when I need to learn c++ on the linux platform.
Linux appears to use pthreads for the most part - okay there's also boost::threads and QT have their own threads too. But with C++11 comes std::thread, a whole new (cross platform and C++ standard) way to do threads.
So I guess I'll have to learn pthreads and std::threads. Ultimately, std::thread seems more important, but there's a lot of legacy code out there, so I'll have to know both.
For thread synchronization on windows, I would use WaitForMultipleObjects to wait for a number of tasks to complete before continuing with further work.
Does a similar synchronization mechanism exist for pthreads? std::threads?
I've had a look at pthread_join, and it seems to have the facility to only wait on one thread at a time. Am I missing another pthread call maybe?
std::thread is boost::thread accepted into C++11 with some extras. My understanding is that if boost::thread gets replaced in code with std::thread it should still compile and work.
boost::thread is based on pthreads design, providing thin C++ wrappers over thread, mutex and condition variables. Thread cancellation though was left outside the scope of C++11, since there was no agreement how it should work in C++.
So, by learning pthreads you also learn std::thread concepts. std::thread adds mostly syntax sugar and convenience functions on top of pthreads C API.
With regards to WaitForMultipleObjects(), neither pthreads nor std::thread provide anything similar to its bWaitAll=FALSE mode, however, it's routinely simulated using pipes and select() on UNIX, or more modern eventfd() and epoll() on Linux. bWaitAll=TRUE mode can be simulated by waiting on all tasks in turn, since it doesn't proceed until all objects are ready anyway.
No, neither pthreads nor C++11 has direct equivalent of WaitForMultipleObjects (i.e. wait for any waitable "handle" type.) pthread_join can only be used to join threads, and only a single, specific thread.
The closest equivalent on posix platforms is to wait for multiple file descriptors using system calls such as select(), poll() or the linux-specific epoll(), but they require you to have a file descriptor to wait on, which is fine for I/O events but requires extra work from you to use them wait for mutexes, condition variables or other synchronisation objects. There are more general event libraries built on top of those system calls, e.g. libevent and libev and Boost ASIO, which support waiting for timers as well as I/O, but still not thread completion, mutex locks etc. with a single function like WaitForMultipleObjects
The alternatives you do have for pthreads and C++11 threads are to wait on different synchronisation types separately. You can wait for timers, wait for threads to complete, wait for mutexes, wait on condition variables, wait for asynchronous results to be ready (std::async in C++11, no direct equivalent in pthreads) ... but there's no call that will allow you to wait a heterogeneous set of those types all at once.
I could give you a really fancy answer but alas, this is where I learned them and it is a good introduction:
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
You use pthread_mutex_t for syncronization and pthread_join probably handles the wait for multiple tasks problem. It works exactly as you would expect.
Based on this, you must call pthread_join for each single thread you have created. Or to use mutexes, if there is a need to synchronize your threads.
Regarding WaitForMultipleObjects, this is generally called a Barrier Sync. Boost has an implementation called barrier. It uses conditional variables to implement it, in posix its a pthread_cond_t
Here is an answer I left recently explaining barrier sync.
Related
Traditional C++ was very straightforward and only a library intended to create threads (like pthread) gave rise to other threads.
Modern C++ is much closer to Java with many functions being thread based, with thread pools ready to run asynchronous jobs, etc. It's much more likely that some library, including the standard library, uses threads to compute asynchronously some function, or sets up the infrastructure to do so even if it isn't used.
In that context, is it ever safe to use functions with global impact like fork?
The answer to this question, like almost everything else in C++, is "it depends".
If we assume there are other threads in the program, and those threads are synchronizing with each other, calling fork is dangerous. This is because, fork does not wait for all threads to be a synchronization point (i.e. mutex release) to fork the process. In the forked process, only the thread that called fork will be present, and the others will have been terminated, possibly in the middle of a critical section. This means any memory shared with other threads, that wasn't a std::atomic<int> or similar, is an undefined state.
If your forked process reads from this memory, or indeed expects the other threads to be running, it is likely not going to work reliably. However, most uses of fork actually have effectively no preconditions on program state. That is because the most common thing to do is to immediately call execv or similar to spawn a subprocess. In this case your entire process is kinda "replaced" by some new process, and all memory from your old process is discarded.
tl;dr - Calling fork may not be safe in multithreaded programs. Sometimes it is safe; like if no threads have spawned yet, or evecv is called immediately. If you are using fork for something else, consider using a thread instead.
See the fork man page and this helpful blog post for the nitty-gritty.
To add to peteigel's answer, my advice is - if you want to fork, do it very early, before any other threads than the main thread are started.
In general, anything you can do in C, you can do in C++, since C++, especially on Linux with clang or gcc extensions, is pretty darn close to a perfect superset of C. Of course, when there are good portable APIs in std C++, use them. The canonical example is preferring std::thread over pthreads C API.
One caveat is pthread_cancel, which must be avoided on C++ due to exceptions. See e.g. pthread cancel harmful on C++.
Here is another link that explains the problem:
pthread_cancel while in destructor
In general, C++ cleanup handling is in general easier and more elegant than C, since RAII is part and parcel of C++ culture, and C does not have destructors.
I noticed that most loggers are advertised as thread safe.
What does it mean?
Are they safe against a specific threading library or can they be safe in any multithreading environment (e.g. PThread, Boost threads, C++11 threads, Win32 threads, OpenMP threads, ...)?
It means you won't get something like this in your log files:
this is the line from the firsThis is line from the second thread
t thread
Usually it means that loggers use required locking when they write to the stream in any supported environment.
If a logger is thread safe that means you can call its functions from any threads (be it pthread or boost or openmp). That is usually done by using mutexes to prevent simultaneous output. Without them your program may output mixed lines or even crash if log is used from different threads.
Hello I have some code that is cross-platform by unsing #ifdef OS,
I have a Queue protected by a CriticalSection on Windows, and by a pthread_mutex_t on Linux.
I would like to implement a Wait(timeout) call that would block a thread until something has been enqueued. I though about using WaitForSingleObject on windows but it don't seem to support CriticalSection. Which Win32 and which Linux functions should I use to Wait and Signal for a condition to happen.
Thank
I think that boost's conditions might be what you need. It is crossplatform so you won't have to bother with different implementations depending on OS.
Another alternative is to use Windows Events with WaitForSingleObject() and the quite new linux eventfd() with select() or poll().
Using Boost will allow you to do threading and synchronization for both platforms without a bunch of ifdefs.
Seems like conditions variable is what I was looking for.
On windows They work with critical Section and SleepConditionVariableCS
On linux pthread_cond_timedwait work with pthread.
Thanks all.
With pthread, a condition variable.
On Windows, it looks like you want a Semaphore. Win32 Semaphores have a counter that starts at zero - at which point the handle is not signaled. As you add items to the queue, you would increase the semaphore counter with ReleaseSemaphore - Each count added to the semaphore will satisfy one call to a WaitforXXXObject function, so, if you added 3 items to a queue, you would ReleaseSemaphore with a count of 3. WaitFor... would then return 3 times before the handle became non signalled again.
You can (sort of) simulate a try with a timeout using TryEnterCriticalSection, but for the most part, if you want a timeout you might be better off using a mutex instead (when you get down to it, a critical section is mostly a wrapper around a mutex).
Another possibility would be to use the Win32 pthreads library, which will probably let your Linux code compile under Win32 unchanged (and you'd simply eliminate your own Win32 code).
This is pretty similar to the threading support that's been added to the C++ 0x library, though it doesn't (even try to) follow the new standard precisely. If you want to follow the standard, you could use Anthony Williams' Just Thread library (warning: fairly reasonably priced, but not free in either sense).
Edit (in response to Billy O'neal's questions): Thinking about it a bit more, there actually is source code easily available that shows most of what's going on. The CRITICAL_SECTION data structure is defined in winbase.h as a typedef of an RTL_CRITICAL_SECTION. That, in turn, is defined in WinNT.h as:
typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
//
// The following three fields control entering and exiting the critical
// section for the resource
//
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread; // from the thread's ClientId->UniqueThread
HANDLE LockSemaphore;
ULONG_PTR SpinCount; // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
If memory serves, the basic idea of how this is used runs something like:
If this thread already owns the critical section, increment RecursionCount and return
Otherwise, do SpinCount attempts to enter CS via fast path using atomic ops on LockCount
Otherwise, wait on LockSemaphore
How can I interrupt a sleeping/blocked boost::thread?
I am using Boost v1.33.1, upgrading is not an option.
Thank you.
A quick perusal of the documentation for boost.thread in 1.33 suggests that there is no portable way to achieve interruption. Thread interruption was introduced (for threads in one of the boost "interruption points") in 1.35.
As a result the only option I can think of is to use signals (which aren't in 1.33 either, so you'll need to fall back on, for example, pthreads) combined with time-outs on any methods that are blocking. Basically use signals to wake threads that are asleep by having them sleep waiting for the signal and timeouts on blocking threads to have them wake up and check to see if they should exit. Unfortunately this is a highly undesirable solution, and to some extent amounts to what newer versions of boost do internally anyway.
If you're using boost.thread, then you should consider upgrading to a more recent version for other projects because 1.33 doesn't support the vast majority of constructs that are essential for multi-threading.
I agree with begray, look into condition variables. If you have threads you want to wake up from time to time, they are what boost expects you to use. If you expect that threads are going to block on other calls (like calls into BSD sockets or something similar) this doesn't help you. You will need to use the timeout facilities of those calls directly, if they exist.
Here's an example, using only facilities available in boost 1.33.1. I haven't compiled it, so there may be small errors. I've included the use of a nebulous Work class, but you don't need to work with shared data at all to use this pattern. Only the mutex and the condition variable are needed.
Work work;
boost::condition workAvailable;
boost::mutex workMutex;
void Producer()
{
{
boost::mutex::scoped_lock lock(workMutex);
UpdateWork(work);
workAvailable.notify_one();
}
boost::mutex::scoped_lock lock(workMutex);
work.SetOver();
workAvailable.notify_one();
}
void Consumer()
{
//This thread uses data protected by the work mutex
boost::mutex::scoped_lock lock(workMutex);
while(true)
{
//this call releases the work mutex
//when this thread is notified, the mutex is re-acquired
workAvailable.wait(lock);
//once we have the mutex we can work with shared data
//which might require this thread to terminate
if(work.Over())
{
return;
}
DoWork(work);
}
}
The producer thread will create one unit of work, and then block. The consumer thread will do the work, and then block. Then the producer thread will set the termination condition and exit. The consumer will then exit.
There is no way to interrupt blocked thread in boost::thread. You need to implement proper thread interruption yourself, using boost::conditional for example.
AFAIK Any existing ways to interrupt running thread (TerminateThread in Windows API for example) only lead to problems (memory leaks one of them).
I'm programming an interprocess communication module (Process A and Process B).
Is there any way the communication thread in B can run (be unlock) as soon as process A finishes a specific action, I mean without B doing any polling nor B waiting too much after A finishes its action?
Which are the concepts/models/design patterns governing these issues? (Something more precise than interprocess synchronization). Which libraries/methods do you recommend?
Thanks.
Edit: I'm looking for methods suitable for each of the three main OSes: Ms Windows, Apple Mac OS X, GNU/Linux.
This is quite hard job:
For Unix OSes you can use:
pthread condition and mutex with setpshared argument.
Note: it is supported well under Linux 2.6, Solaris, but it does not supported FreeBSD and Cygwin (don't know about Mac OS X)
For Unixes you may also use named semaphores, but I don't know the support level of them
For Windows there are some events...
This is hard job, especially for IPC...
So if you want something portable, I'd suggest to take a look on Boost.Interprocess that has conditions and mutexes...
But make sure that all feature supported on all OSes you want to support.
Things you should note about Boost.Interprocess
Check carefully level of support for each Unix OS you need to work with, because Boost.Interprosess uses pthread_* functions that are not always supported... and then fails back to emulation -- check the quality of such emulation
Also, check how this stuff works on Windows -- as far as I know that there is no "in-shared-memory" mutexes in Win32 API, generally named objects should be used, so check what is supported and how.
EDIT: I mistakenly thought you needed inter thread synchronizing, Revised for IPC
I think you need something like waitable events.
In Windows you can use CreateEvent(), to create (or get an existing) named, auto-reset event.
When process A completes processing, it should call SetEvent(), while process B should call WaitForSingleObject() to sleep until completion (or timeout).
Alternately, you can use semaphores created by CreateSemaphore(), initialized to 0.
Process A signals completion by calling ReleaseSemaphore(), while process B again uses WaitForSingleObject() to wait for completion.
Under Linux and OS X you can use semaphores to a similar effect.
use sem_open() to create a named semaphore, with 0 as its initial value.
When process A completes, it should call sem_post() to increment the semaphore, while process B should call sem_wait() to sleep until completion.
NOTE: the semaphore method may allow multiple completions to be signaled, you should handle this by setting a maximum count under Windows, or checking the current sem value for sanity with sem_getvalue()
I think condition variables fit what you're trying to do, here's a sample that would work on Linux and OSX
#include <pthread.h>
/* no error checking, quick and dirty sample */
pthread_mutex_t g_mutex;
pthread_cond_t g_cond;
int a_done = 0;
void init(void)
{
pthread_mutex_init(&g_mutex, NULL);
pthread_cond_init(&g_cond, NULL);
}
void thread_a(void *arg)
{
/* do something here... */
pthread_mutex_lock(&g_mutex);
a_done = 1;
pthread_cond_signal(&g_cond);
pthread_mutex_unlock(&g_mutex);
}
void thread_b(void *arg)
{
/* wait for a to complete */
pthread_mutex_lock(&g_mutex);
while (!a_done)
pthread_cond_wait(&g_cond, &g_mutex);
a_done = 0;
pthread_mutex_unlock(&g_mutex);
}
Under Windows, you can use pthreads-win32, or native condition variables under Vista, see the MSDN Condition Variables page for more information.
References:
pthread_cond_wait
pthread_cond_signal
If your OS supports signals you could unlock a mutex from a signal handler and send the signal from process A as soon as you finish the task.
Process B would be waiting on a mutex or other synchronization tool and A would be working on whatever, then when finishes sends signal USR1 for example, and USR1 handler in process B unlocks the corresponding synchronization tool.
The most common is to use select()/poll(). Both can check several file descriptors if there's input available. Both receive a timeout parameter - this will prevent busy wait, which may consume 100% CPU. This is very suitable solution for small/medium applications.
Another approach is to make polling in separate thread.
If you're going to develop a big application it's worth to look towards ACE framework or
boost. These frameworks are cross platform solutions, well designed and well tested.
Well, in my opinion and experience, the best way to do that in a portable and simple way is to use sockets. Plus you get the possibility to have the two processes on different machine (if needed). Plus you can extand the communication to handle more than synchro.
If you don't want to poll, use a thread that wait for a synchro message on a socket. You read the socket in a blocking way. When you receive the message you use a standard multithread synchronisation to handle your synchronisation. In your case as B should wait till A ends, you just have to read in a blocking way in your process.
To be portable use a portable socket library like boost or ptypes or whatever.