I'm looking forward to an interview in C++ in the coming weeks. (yay) So I have been relearning C++ and studying up. Unfortunately I have realized that I've never implemented threads in C++, and am somewhat concerned about a quiz on concurrency.
As far as I can tell, C++ uses pthreads in Linux and some other device in Windows. Is this correct? Is there another industry standard, more OO way to handle threads in C++ that I should be expected to know? And are there any good web resources that you can point me to for practicing and learning threads in C++?
Thanks!
There is a boost threads library which is probably the closest to a standard.
Generally threads are supplied by the OS so you get whatever the OS supplied. Also peoples first exposure to threading is often in a GUI, to allow a background calculation to not block the GUI, and so people tend to use the thread functions supplied by the particular GUI framework (MFC/Qt etc)
Currently C++ is entirely unaware that threads exist. Different OSes provide threading libraries to make them available. The next version of C++, so called C++0x, is going to make a thread library standard. If I were to start a multithreaded app today I would go with either boost threads or the threads that were a part of any package I might be using i.e. QT or WxWidgets.
Well, until C++0x gets here, there is no standard way to do threading in C++. You can use whatever facilities your operating system provides. So yes, if you are on a UNIX-like operating system, you can use pthreads. On Windows, you can use the Windows API.
There are 3rd party toolkits out there that attempt to provide a uniform and portable threading API, e.g. boost threads and QT.
It is also not difficult to write your own portable abstraction layer either. We did this because the boost API didn't have everything we needed several years ago (e.g. no way to set priority).
In windows the only way to create threads is using the win32 API. Every library you may have that creates threads on windows eventually uses win32 CreateThread()
QT Contains a nice C++ wrapper around a thread that is cross platform. Usually a good practice is to have a MyThread class that contains all the nitty-gritty details of setting up a thread, checking for error codes, getting it's exit code and the like. The MyThread class would have a pure virtual function called run() which is intended to actually do whatever you'd want the thread to do. The user of the MyThread class is expected to inherit from it and implement run() this way you can isolate the user of the class from the details for actually creating the thread.
MyThead also needs to have a method start() which initiates the thread. The thread would start at some entry point inside the class (this usually needs to be a static method) and then this eventually leads to the user's run() method to be invoked.
Beyond Qt, wxWidgets, Boost and native, OS-provided threading facilities, you can just Google around for thread libraries for C++. They are probably more portable and lightweight as well (if all you are looking for is threading). However, if you have a need for more facilities and the aforementioned libraries provide them, then go ahead and use them. Boost is especially good, it has other facilities as well, but admittedly it's threading library, as Brian Neal said, is limited in some regards.
For your interview, neither boost nor qt is helpful at all. you could just use them as the high level libs and interfaces, and no one would ask you how to use boost or qt in such an interview.
For understanding threading and mutex etc, see a document from http://code.google.com/p/effoaddon/downloads/list, named EffoAddons.pdf.
Raw source
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/thrd/src/thrd/thrd.cpp,
high level abstract interface
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/thrd/include/thrd_i.h,
and code support wait and signal
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/queue/include/iqb_ops_i.h.
you'd better study something underlying, not just high level interfaces, though write C++.
I've seen several 'real-world' implementations of threading using C++, and they have all been implemented by someone's writing a Thread class to wrap the underlying O/S API
For example, on Windows there's a CreateThread API: your Thread class would pass its this value to the void* lpParameter parameter of the CreateThread API; and your LPTHREAD_START_ROUTINE, which you implement as a private static method of the Thread class, then needs to cast void* back to Thread*' in order to get theThread` instance.
Related
I'm considering two options to run asynchronous code: Qt Concurrent and std::async. Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent. However std::async also seems good and supported by all major compilers.
Should I use Qt Concurrent or std::async for new code? What else should I look for when comparing the two?
Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent
I would say, it is not so simple. I would personally utilize the standard library as much as I can. However, there are constraints to take into account:
Do you need to support your software on platforms not supporting at least C++11?
If the question is yes to that, using Qt solutions is a better option in a Qt based software. That being said, even for that, you could have different Qt solutions depending on your need. One is the thread weaver from KDE, but let us not go that far for now...
Another question, that you could ask from yourself:
Do you already have an existing code base where that is used throughout?
Depending on the answer, this could also provide further aspect for the decision, whether you prefer consistency, or forward thinking.
There is also another question here to be asked:
How much of QtConcurrent do I need?
Depending on the exact answer, it may or may not be a better alternative. Note that, not every functionality of QtConcurrent is in the standard library just yet, for instance something like QFutureWatcher with the Qt signal-slot mechanism.
So, yes, as a Qt user, I would suggest to use the standard library as much as possible. These days, Qt even explicitly depends on them, so will not run on platform not supporting it. Also, the general direction put seems to be this in Qt Project proper. For instance, lots of stuff got obsoleted in the QtAlgorithms, but that is just one of those.
Qt Concurrent lets you run a function in another thread using QtConcurrent::run(). So i think you can only compare QtConcurrent::run() with std::async.
Qt Concurrent is so sophisticated and has many useful features. It includes APIs for parallel list processing and lets you create multi-threaded programs without using low-level threading primitives such as mutexes or semaphores. It also adjusts the number of threads used according to the number of processor cores available.
I think using Qt Concurrent is so cool because of its high-level APIs and ease of use.
glib has a data structure called GAsyncQueue, which allows inter-thread communication with no semaphores/locks/etc., and even makes trivial the task of implementing a producer/consumer solution. If two different threads push data to a GAsyncQueue structure, the push function internally implements the mutually exclusive access to the queue; more awesomely, if a thread calls the pop function, and there is no data there, the calling thread blocks until some data is pushed into the queue by some other thread. All of this is done in a thread-safe manner, transparently to the developer.
As much as I like it, though, this library was built for C, and there might be better alternatives for higher level languages. I'm thinking about using glib anyway, but it feels odd to use a C library in a C++ code...
So, the question is: is there a C++ recommended equivalent for glib? More specifically, is there a more recommended C++ library that provides the same functionality as GAsyncQueue?
There is absolutely nothing wrong with using C in a C++ program (after all, C++ implementation is heavily based on C runtime, for example C++11 thread support cannot live without pthread library, at least on UNIX®-like platforms). I would definitely not choose the tool/library only and entirely basing on the language it is written in. But if you must use something else, then glib is not the only library in the world that provides provides asynchronous message passing (by the way, it doesn't really look like it supports IPC). Anyhow, here is a list of C++ frameworks that immediately come to my mind (in random order, as random as my thoughts):
Intel Threading Building Blocks
Boost MPI
Boost.ASIO
Qt
Each one has its own strengths and weaknesses, and which one to use really depends on what exactly your requirements are. I can only recommend you to pay attention to overall application architecture and how well the asynchronous message passing would fit into all of the components of your application. For example, in more or less complex applications that involve more than simple message passing, such asynchronous queues are oftentimes integrated with the event notification mechanisms in use (for example, OSX is built around kqueue/GCD).
Hope it helps. Good Luck!
I have an MFC application to which I want to incorporate multi-threading. Originally I was thinking of using Boost.Thread because of the general ease of development with boost. However, I'm wondering if there are any gotchas and if I should use AfxBeginThread to be safe in an MFC context?
I found this Microsoft article: Multithreading: Programming Tips. It says:
Accessing MFC Objects from Non-MFC Threads
If you have a multithreaded application that creates a thread in a way
other than using a CWinThread object, you cannot access other MFC
objects from that thread. In other words, if you want to access any
MFC object from a secondary thread, you must create that thread with
one of the methods described in Multithreading: Creating
User-Interface Threads or Multithreading: Creating Worker Threads.
These methods are the only ones that allow the class library to
initialize the internal variables necessary to handle multithreaded
applications.
I was intending to use the threading in a model view presenter context in order to multi-thread some long running presenter tasks. As the presenter needs to communicate with the view I think that most likely qualifies as accessing MFC objects (at least indirectly). Based on that I've decide to go for AfxBeginThread thread creation method for now.
Try to read this article, in the section Concurrent Programming Improvements this is the best way do things on the Windows platform right now.
Boost slows down your builds and contains a lot of extra stuff you don not need.
Also check the MSDN site on parallel programming for more details.
One benefit of using boost::thread is that its interface resembles std::thread's. There are, however, a few differences. If you ultimately want to use std::thread, boost::thread will be a straightforward transition.
Just include the following header file and there should be no problems:
#include <boost/thread/win32/mfc_thread_init.hpp>
#include <boost/thread.hpp>
If you have MFC project, please DON'T introduce boost to it. Use MFC API wherever you can. Since it has some stuff for threading support, you really don't need one extra library (especially boost) for that.
At the time I write this, it is still unsafe because of this issue in Boost.Thread:
http://boost.2283326.n4.nabble.com/Fwd-Thread-Solution-to-conflict-with-MFC-td3477977.html
(short version that anybody trying this discovers soon enough: merely linking with Boost.Thread causes asserts in MFC initialization)
I'm experimenting with multithreading in Windows and was wondering whether I should
use Win32 API
use POSIX Threads for Windows
Learning Pthreads would be useful if I tried to develop such applications on different platforms - but am I losing anything by not learning Win32 API? Or are both similar enough so that learning one allows me to figure out the other easily?
Use Boost Threads. When C++0x comes along, we will have std::threads. Boost threads has the closest implementation to std threads.
else use pthreads. Pthreads is second closest to std::threads, and formed the main basis of std threads and boost threads.
else do windows threading directly. You can still learn how threads work, and form a mental model of things. It just tends to use synchronization primitives that are a bit non-standard.
If you're going to do much Windows programming, it will pay to learn the basic Win32 threading constructs: critical sections, interlocked functions, CreateThread, WaitFor*Object, etc. These aren't hard to understand, and they translate transparently to equivalent objects in other threading frameworks.
However, for more advanced threading constructs such as semaphores, events, etc., I would use the pthreads library, since the documentation on those tends to be clearer and examples more abundant.
If you're using C/C++, try to use the thread functions of the C/C++ runtime.
If you use the Win32 (or other non-CRT functions to create threads) the CRT might not be initialized correctly in the new thread, causing all kinds of problem (you can read about it here: http://www.codeguru.com/forum/archive/index.php/t-371305.html).
However, most thread-functions (in the CRT, Win32 or pthread) are all based around the functionality to create threads, synchronize threads and destroy threads. In practice this isn't always that easy to use.
In the last year, there is a trend to go to task-based threading (well, I call it that way, I don't know what the official name is). Instead of starting a thread and then executing some logic in it, in task-based threading you create a task and then ask the 'threading logic' to execute the task.
Systems that support this new way of working with threads are:
Visual Studio 2010 (we'll have to wait a few days for it)
Intel Threading Building Blocks
Visual Studio 2010 even has (it seems) special debugging logic to debug the 'parallel tasks'.
Take a look at std::thread
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html
And a introduction
http://www.devx.com/SpecialReports/Article/38883
I've found that sticking with pthreads saves my sanity on three counts:
I don't have to fight through
WinAPI docs, which aren't habitually
of any quality.
Anyone that does much with threads
can help out with
pthreads. I've found infinitely more good sources of information about pthreads online.
Whenever I implement anything more
complicated that "Hello World" with
the WinAPI, I find it takes far
longer than one could reasonably
expect. That's just my empirical
input, though.
As far as capabilities are concerned, I've never found pthreads to be lacking in anything, so I don't think I've ever found the need to look elsewhere. There is also a great deal to be said for learning a library that you'll be able to use in any environment you tackle.
I am a java programmer but currently working on the c++ language. Unlike java, the c++ does not define any threading utility. It is a little hard for me to implement a multi-threaded application in c++. Is there anyway someone can implement his own threading library using c++? Must you be able to grasp some concept of assembly language? I have in many occassions tried to create a thread from the OS specific features but i have always failed.
Can someone help out?
Given your level of expertise, perhaps Boost Threads would be helpful?
http://www.boost.org/doc/libs/1_37_0/doc/html/thread.html
In answer to your other questions, of course you can implement your own threading library. No you do not need to know any assembly language to do so, but there are no C standard library functions to help you, you will need to use the OS specific libraries. For example on windows you use the beginthreadex CRT function, which ends up calling the CreateThread Win32 system call, but on many unixes you would use pthread_create.
Other than starting a thread, you probably want some synchronization primitives, the Boost library delivers on that front as well. If you want to roll your own, on Windows look into CreateMutex, WaitForSingleObject and ReleaseMutex or the CriticalSection functions, on unix look into pthread_mutex_init.
I would suggest that you use an existing multiplatform library as Boost, ACE, POCO, QT...
ACE has quite a bit of thread classes, the simplest to use is probably ACE_Task_Base. You inherit from it and provide an implementation for int svc() method. That is the method that gets called when you activate the thread.
class WorkerThread : public ACE_Task_Base
{
public:
int svc() { ... }
};
int main()
{
WorkerThread worker;
worker.activate();
worker.wait();
}
With POCO you have to use the Runnable interface and the usage is close to what you would get with Java threads (if you implement Runnable, not extend Thread):
class Worker : public Poco::Runnable { ... };
int main()
{
Worker worker;
Poco::Thread thr;
thr.start( worker );
thr.join();
}
Boost threads (recommended) are a little different. Instead of implementing/extending an interface it depends on the operator() being defined. You create a thread passing it an object that implements operator()(). The thread starts by calling that method. The good part is that it is really simple to combine with boost::bind to create a fake functor (object implementing operator()):
class X { public: void method( int argument ); }
int main()
{
X x;
boost::thread thr( boost::bind( &X::method, &x, 100 ) );
thr.join();
}
The snippet will create an object of type X. With bind you create a functor that wraps a call to the method X::method applied on the object x, passing it 100 as the method argument.
While this differs most from the Java perspective it is also the most flexible approach, as you can decouple the threading model from the real working code. No need to fit a particular interface. This is also the upcoming standard threading interface.
Besides the libraries other have mentioned, there is Intel's Threading Building Blocks. It is a open source (GPL2 with linking exception), cross platform library from Intel.
if you are using POSIX systems such as Linux or Unix or even windows you can use pthread
if you are stuck on a windows machine without .NET i think you don't have much choice but to learn win32 threads. Of course there are plenty of "win32 thread libraries" on the tubes.
Boost
CodeProject
SourceForge
I suspect that most large code repositories have some kind of custom implementation...
The easiest choice win windows could be going for .NET threads which are much easier to deal with. You can have Visual C++ .NET for free
Pthreads can be used in C++. I usually just write some simple wrappers around them.
Also, if you're just trying to splut up a bunch of low level loops, please check out OpenMP. It's insanely easy to use.
I have a little C++ project that has a threading library here. The purpose is pretty specific, but it can serve as an example perhaps.
http://github.com/mikelikespie/reccage
Another easy to use, platform independent concurrency HEADER ONLY library:
https://github.com/zlateski/zi_lib/tree/master/zi/concurrency/
examples are under test directory
Following URL states "A platform-independent, multi-threading and synchronization library for C++"
http://zthread.sourceforge.net/
Best of luck to implement the same.