is there any way to set Processor affinity for ITK (3.20.1) threads. I was looking into ITK::MultiThreader class which has "SetGlobalDefaultNumberOfThreads". but i am not finding any function/method which is saying anything about affinity.
any help would be appreciated..
In the version that I have installed (3.18), it seems that this feature is not supported. However, looking at the MultiThreader header file, I noticed that the implementation relies on the native OS thread mechanisms. This means that on linux, pthreads are actually spawned, and pthread_t are directly used for ThreadProcessIdType, which means that you might be able to use the linux proprietary extensions for core affinities.
Quoting myself from this answer to another question:
Unfortunately, the posix thread API doesn't provide a way to set cpu affinity for threads. You may use the non portable extension provided on the linux platform pthread_attr_setaffinity_np, with the cpuset family of functions to configure a thread affinity.
Since the thread will be already running, you will need to get the thread attributes before being able to set its affinity. Linux provides one more non portable function for that: pthread_getattr_np.
Also, the cpuset feature must be built in the kernel, however this should be the case on most platforms with multicore support.
references:
cpuset
pthread_attr_setaffinity_np
pthread_getattr_np
Related
Working with threads in Qt5, how can I set a single thread's CPU affinity?
I want to specify a mask of available CPU cores that the thread may run under.
In other words, what is the Qt5 equivalent to Posix thread's pthread_setaffinity_np() ?
Can I do this for threads managed by QThreadPool?
Usually that sort of things is done by extracting the native thread handle and then doing whatever system specific stuff necessary, as no accepted cross-platform API exists for low level thread management.
Indeed, if we inspect the source for the qthread_unix.cpp we will see the following:
Qt::HANDLE QThread::currentThreadId() Q_DECL_NOTHROW
{
// requires a C cast here otherwise we run into trouble on AIX
return to_HANDLE(pthread_self());
}
And in qthread_win.cpp the implementation will differ in the expected way:
Qt::HANDLE QThread::currentThreadId() Q_DECL_NOTHROW
{
return reinterpret_cast<Qt::HANDLE>(quintptr(GetCurrentThreadId()));
}
So, it is responsibility of the application code to do the proper low level actions pertaining to each platform it is expected to run on.
Qt doesn't provide any public APIs for setting processor affinity. There's definitely no way to do this for a QThreadPool, which doesn't even provide an API for accessing the QThreads within the pool.
For explicitly-created QThread objects, you could try using the QThread::getCurrentThreadId() function to return a native "handle" to the thread, and then pass that to your system's thread-management library calls. But I would strongly recommend against this. The docs explicitly state:
Warning: The handle returned by this function is used for internal purposes and should not be used in any application code.
If you're building for a specific platform, you might be able to mix calls to your OS's library (e.g., pthreads), but that will not be portable and I have no idea if it will work.
Your best bet is probably to manage the CPU affinity of the whole application from the command-line. If you're on Linux, taskset is the way to go. For Windows, take a look at this SO answer. Unfortunately, Apple seems pretty determined to prevent users from setting thread affinity, at least from the command line.
Can a fiber created in thread A switch to another fiber created in thread B? To make the question more specific, some operating systems have fibers natively implemented (windows fibers),
other need to implement it themselves (using setjump longjump in linux etc.).
Libcoro for example wraps this all up in a single API (for windows it’s just a wrapper for native fibers, for Linux it implements it itself etc.)
So, if it's possible to migrate fibers between threads, can you give me an example usage in windows (linux) in c/c++?
I found something about fiber migration in the boost library documentation, but it's not specific enough about it's implementation and platform dependence. I still want to understand how to do it myself using only windows fibers for example (or using Libcoro on linux).
If it's not possible in a general way, why so?
I understand that fibers are meant to be used as lightweight threads for cooperative multitasking over a single thread, they have cheap context switching compared to regular threads, and they simplify the programming.
An example usage is a system with several threads, each having several fibers doing some kind of work hierarchy on their parent thread (never leaving the parent thread).
Even though it's not the intended use I still want to learn how to do it if it's possible in a general way, because I think I can optimize the work load on my job system by migrating fibers between threads.
The mentioned boost.fiber uses boost.context (callcc/continuation) to implement context switching.
Till boost-1.64 callcc was implemented in assembler only, boost-1.65 enables you to choose between assembler, Windows Fibers (Windows) or ucontext (POSIX if available; deprecated API by POSIX).
The assembler implementation is faster that the other two (2 orders of magnitude compared to ucontext).
boost.fiber uses callcc to implement lightweight threads/fibers - the library provides fiber schedulers that allow to migrate fibers between threads.
For instance one provided scheduler steals fibers from other threads if its run-queue goes out of work (fibers that are ready/that can be resumed).
(so you can choose Windows Fibers that get migrated between threads).
i was wondering how to force a program in C++ in Visual Studio, run on specific core/cores (on computers who has more than one).
i found this article, but in refers to C in Linux (and i am using Visual Studio on windows)
also, does the windows version I'm using, matter?
It is possible to use the Windows API function SetThreadIdealProcessorEx(). This function is applicable to Windows 7 or later. On older systems, it is possible to use SetThreadIdealProcessor(), albeit with some more limitations.
This, according to remarks at the first link
Specifying a thread ideal processor provides a hint to the scheduler about the preferred processor for a thread. The scheduler runs the thread on the thread's ideal processor when possible.
I'm not aware of any function that forces the scheduler to run a thread on a specified processor. So giving a hint, which the scheduler will attempt to act on, is probably the closest you can get to meeting your requirement.
It would probably be advisable to also use SetProcessorAffinityMask() as well, which works to specify processors on which a process may run, since it would seem unlikely that a thread can run on a processor that is not within its parent process's affinity mask.
Read the documentation for these functions carefully, because the system itself can impose limits on which processors a process may run.
I want to build a portable and efficient server in C++; it will have lots of clients trying to connect at the same time, so it must be able of handling each request parallel.
I have been trying to find documentation, guides... etc. for multithreading. I have found a lot about POSIX Pthread, but almost nothing for GNU Pth (apart from the official manual in gnu.org).
So, can anyone explain me the difference between POSIX Pthread and GNU Pth? Please, I want the response not to be a copy of Wikipedia's contents (keep in mind that I'm an absolute newbie to multithreading). I want my server to be portable and efficient between all *nix-based systems, keeping away of using heavy fork()s.
Thanks for your help.
PS: I think it's better to ask this here: what about Windows? Are Pthreads or Pth an option there? If not, what is the API for that operating system?
Use Pthreads, it's much more widely used, so there is far more information and support available for it. I've never met anyone who actually uses GNU Pth. Or better yet if you are using C++11 use std::thread and if not then use boost::thread.
So, can anyone explain me the difference between POSIX Pthread and GNU Pth?
Pthreads is a cross-platform standard for pre-emptible multithreading, meaning (usually) the OS kernel manages the threads and the OS scheduler decides when each thread gets to run (if you have a single core only one thread can run at a time, if you have multiple cores multiple threads can run at a time). The OS scheduler could pause any thread at (almost) any time and let another thread run, so each thread gets a limited "time slice" and then other threads get to run.
GNU Pth is a non-preemptible user-space threading library, meaning the threads and which ones run at which time are decided in user-space not by the kernel. Some people say programs using non-preemptible threading libraries are easier to understand, because your thread won't get paused at arbitrary times for another thread to run.
I want my server to be portable and efficient between all *nix-based systems, keeping away of using heavy fork()s.
fork is not heavy on UNIX.
what about W*ndows? Are Pthreads or Pth an option there? If not, what is the API for that operating system?
There are pthreads APIs for Windows, but they're not native to the Windows OS. I don't know if GNU Pth works on Windows - I doubt it, unless you use Cygwin. Windows has its own Win32 thread model.
Using std::thread or boost::thread is portable to POSIX platforms and Windows, and makes certain parts of the API easier to use (specifically, locking and unlocking mutexes can be easily done in an exception safe way and condition variables are easier to use.)
Gnu PTH is for a very limited use case: you want to use a multi-threaded implementation paradigm but you don't want to use multiple CPUs or cores and you don't want to rely on any OS or kernel-level support. Since almost all general-purpose CPUs now have multiple cores, this use case is increasingly irrelevant.
Windows has a separate threading model from POSIX; if you want your application to be cross-platform it is best to use a cross-platform threading library such as boost::thread.
I think GNUs PTH is meaned for C in the first place. You can use it on C++ too but C++ have its own anyway.
There are quite some applications using pth like low-level burning tools (and so GUI-Tools like K3B and Brasero depend on pth), also GnuPG uses PTH, the package management of Archlinux and some multimedia stuff.
On Windows its always a bit complicated. Microsoft did never get over the fact that C is the Programming Language from/for UNIX-Systems and so is suffering the NIH Symptome (Not Invented Here)
So they do a lot of stuff without any advantage just to be different.
If you use an Application which should run everywhere and its not low-level, use Qt with its QThreads and QThreadPool
Its 100% the same on all operating systems
You need much less code
If you write an "low-level" application i recommend to split your applications into backends and frontends and write a own backend for each OS and use the library which will do the least problems.
I'm writing portable code for multicore machines and I want kernel level threads so the threads can use more than one cpu. After reading QThread documentation on Qt Assistant I still haven't found any hints.
On Windows XP the multithreading example (mandelbrot) from the QtSDK used only one core. So I guess on XP only user level threads are possible. I haven't tested that on Linux or OSX so far since there isn't the full SDK installed.
EDIT: The example given in the SDK is stupid - it only uses one thread for those calculation so the binding to only one core was misleading. Buildig a sample myself I could use all cores, so on XP with mingw/GCC Qt uses kernel level threads.
So, what kind of threads are used by QThread? Is it possible to specify what kind of thread to use?
Multiple processes are also an option in combination with shared memory.
Edit
http://doc.qt.io/qt-4.8/thread-basics.html gives a nice introduction.
I don't know about Windows, but on Unix it is using pthreads. QT isn't exposing API for CPU affinity because it needs to be platform- and hardware-independent. The QThread distribution across CPUs is left to the OS scheduler, you can't hint it via some QT API.
From QThread Class Reference:
A QThread represents a separate thread of control within the program; it shares data with all the other threads within the process but executes independently in the way that a separate program does on a multitasking operating system.
In your terms, it's a "kernel" thread.
Also, the conclusion that "only user-level threads are possible" on Windows XP is surely incorrect.