This question refers to boost::threadpool::pool, and there's docs about it here on sourceforge, but I can't find it in the boost docs.
Why is it called boost if it's not on boost?
PS: I know how to use Boost::ASIO's io_service to create a thread pool, but I'd like to understand what this boost::threadpool is.
As a former helper with Boost.Thread maintenance, I was often asked why Boost.Thread doesn't provide a thread pool. The simple answer is that it really is too easy to roll your own, for example here is a perfectly fine threadpool implementation in only a few lines of C++.
It's too small a thing for Boost, and too much bike shedding would happen on trying to submit a general purpose thread pool. So you can misuse ASIO to implement a thread pool (also easy), roll your own, or just use the thread pool in the C++ 11 standard library accessible via std::async.
Related
I am using a library named "JSON for Modern C++" (https://github.com/nlohmann/json) which is pretty slick, letting me use JSON configuration files by a C++ program that are shared with a Javascript server side application. This library essentially creates another datatype that is accessed and manipulated in way that is very close to the same as a Javascript JSON objects.
My question is, do I need to be concerned about thread safety on JSON variable accesses and manipulations or can I trust the library is thread safe. I've looked in the documentation and I don't see it say it is thread safe but I also don't see anywhere that says it isn't thread safe.
Is anyone else using this library in a multithreaded environment? Did you need to protect it yourself or did the library protect itself. Maybe I'm really lucky and the repository author nlohmann will answer directly!
Any help is greatly appreciated!
nlohmann library is NOT thread safe. Take a look at the header file. It's a single one. There's no mutexes, locks or atomics or anything related to threads.
https://github.com/nlohmann/json/blob/develop/src/json.hpp
You are responsible for protecting against concurrency of multiple threads accessing this data.
Per the author in About thread safety #2366:
No, the container is like a map or a vector: you have to ensure thread safety yourself.
I am looking through docs and somehow I am blind or missing important information, whether C++ classes are thread safe or not. the Session class specifically? Any experiences or anybody who found the info actually? Because it seems to me, that I have to get through sources otherwise...
Thanks!
/ip/
I found the answer in the end. Yes, they are actually thread-safe.
In the C++, AMQP Qpid has its own mechanism for processing, it creates a small number of threads(I believe comparable to the number of cores), incorporating thread pool like behavior and thread safety is ensured by processing at any given time on one thread at the time and some locking is ensured for asynchronous operations done by code using given DLL.
With C++/CLI port it is rather worse, there are locks used in the .Net part and I believe, that some parts of the C++/CLI port are very performant as they could be...
I am currently in the process of refactoring an mid-sized software project. It contains a central kernel-like class that is used by multiple threads. Currently, this class uses a Glib::Dispatcher for handling signals that are emitted by multiple threads. Since one goal of the refactoring proccess is to get rid of glibmm entirely (since Qt shall be used as the new framework), I am trying to figure out a way of how to "simulate" the dispatcher functionality using Boost. I already looked into Boost.Signals and Boost.Signals2, but neither one of these libraries seems to offer an alternative to the dispatcher.
To clarify what the dispatcher shall do, here's a short description from the official documentation:
Glib::Dispatcher works similar to sigc::signal. But unlike
normal signals, the notification happens asynchronously through a
pipe. This is a simple and efficient way of communicating between
threads, and especially useful in a thread model with a single GUI
thread.
No mutex locking is involved, apart from the operating system's
internal I/O locking. That implies some usage rules:
Only one thread may connect to the signal and receive notification, but multiple
senders are allowed even without locking.
The GLib main loop must run in the receiving thread (this will be the GUI thread usually).
The Dispatcher object must be instantiated by the receiver thread.
The Dispatcher object should be instantiated before creating any of the
sender threads, if you want to avoid extra locking.
The Dispatcher object must be deleted by the receiver thread.
All Dispatcher objects instantiated by the same receiver thread must use the same main
context.
Could you give me some pointers in the right direction? Is this the sort of functionality I can achieve using Boost.Signals or Boost.Signals2?
Edit: As a commenter rightly pointed out, using Qt would perhaps be an option. However, the class that I am refactoring is very low-level and I do not want to add this additional dependency.
I think there is no simple way to do that, removing Glib in flavour of boost won't solve the problem which is more an architechtural issue than anything else. Replacing with Boost not gonna fix the design issue.
You should model your own signal interface, and try to adapt for each library, including Glib in the first place since it is already working, adding another indirection level to your problem will let you fix that issue.
Boost can help you if you look at boost::function. I dont consider replacing glib with boost to be a real step forward, boost is not a graphical library and it will be required at some point to add an interface with an implementation layer to your graphic engine.
I have now opted for a total rewrite of the class in question. It turns out that I do not require the dispatcher functionality in the way it was provided by Glib. Instead, it was enough to use the normal boost::signals2 signals, coupled with some signals from Qt for the actual graphical interaction.
If I'm not wrong there is no easy way to make a c++0x thread cancellable. I'm wondering if it's legal to use GCancellable mixing it with c++0x thread.
If the answer is
No
I guess I should use glib threads or it's not so legal too?
I am not very familiar with GCancellable. After a quick read through, it appears to be a hierarchical notification system.
If that is the case then yes you can easily mix GCancellable with std::thread.
There is no easy way to make a std::thread cancellable.
This is wrong.
There is no non-zero cost way to make all std::threads cancellable.
This is correct.
The problem is providing a general solution. Notification is easy enough. The hard part is making sure the thread sees the notification. The thread may be blocked on a mutex or IO. You cannot just kill the thread. All sorts of bad can occur.
Each individual implementation is free to implement their own cancellation system tailored to you particular needs.
If you need to be interruptable from a blocking mutex, make sure you only use timed_mutexes, and that you call g_cancellable_is_cancelled frequently enough that your thread will cancel as needed.
You mean something like boost's interruptible threads?
This aspect didn't make it into the standard but you can derive from std::thread to offer a protected check_interrupted() method which throws if someone called a public interrupt() method.
I wouldn't bother mixing with Gnome's thread constructs. Sounds like more trouble than it's worth.
I'm new to wxWidgets (C++), and threads for that matter. What should I be aware of concerning shared resources? Should I implement some sort of semaphore-based locking of resources that may be used by both the GUI thread and the worker thread(s)? Does wxWidgets offer some capability for dealing with this?
Not sure what your choice of threading library is at this point but in your case I'd use wxThread (see here & here for documentation).
What should I be aware of concerning
shared resources?
See the Important notes for multithreaded applications part here for wxWidgets specific multi-threading issues.
Other than that the 'usual' concerns about shared resources apply.
Should I implement some sort of
semaphore-based locking of resources
that may be used by both the GUI
thread and the worker thread(s)? Does
wxWidgets offer some capability for
dealing with this?
wxWidgets already implements a number of synchronization objects, see here.
As a side note prefer using the RAII locker helpers (wxMutexLocker, wxCriticalSectionLocker) instead of explicitly acquiring/releasing.