Given the following bit of code, I was wondering what the equivalent bit of code would be in linux assuming pthreads or even using the Boost.Thread API.
#include <windows.h>
int main()
{
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_HIGHEST);
return 0;
}
The equivalent to SetThreadPriority in linux would be pthread_setschedprio(pthread_t thread, int priority).
Check the man page.
EDIT: here's the sample code equivalent:
#include <pthread.h>
int main()
{
pthread_t thId = pthread_self();
pthread_attr_t thAttr;
int policy = 0;
int max_prio_for_policy = 0;
pthread_attr_init(&thAttr);
pthread_attr_getschedpolicy(&thAttr, &policy);
max_prio_for_policy = sched_get_priority_max(policy);
pthread_setschedprio(thId, max_prio_for_policy);
pthread_attr_destroy(&thAttr);
return 0;
}
This sample is for the default scheduling policy which is SCHED_OTHER.
EDIT: thread attribute must be initialized before usage.
You want:
#include <pthread.h>
int main()
{
int policy;
struct sched_param param;
pthread_getschedparam(pthread_self(), &policy, ¶m);
param.sched_priority = sched_get_priority_max(policy);
pthread_setschedparam(pthread_self(), policy, ¶m);
return 0;
}
The POSIX standard includes pthread_setschedparam(3), as mentioned by various other answers. Mostly this POSIX thread library function is mentioned when talking of real-time threads, but the POSIX standard does not limit its use solely to the domain of real-time threads. However, in Linux its use is only really meaningful if using real time scheduling classes SCHED_FIFO or SCHED_RR as only those scheduling classes allow more than one value for the priority parameter. See this stack overflow answer for an illustration.
Fortunately or unfortunately, it is a matter of perspective, it seems both main stream Linux POSIX thread library implementations (the obsolete LinuxThreads and the current NPTL implementation) are not fully POSIX compliant in that the "nice value" is not process specific but thread specific parameter, so it seems you could use setpriority(3) to change the niceness of a thread in Linux. This claim is based on the compatibility notes in pthreads(7) manual page (search for "nice value" in that page); I have not actually tested in practise (straightforward thing to do).
Should you decide to use the POSIX incompliant way of changing the thread niceness, note that there is the lurking possibility that somebody decides to fix the mentioned non-compliance, in which case there seems to be no way of changing the thread priority in Linux if using normal scheduling class (SCHED_OTHER).
Something like pthread_setschedparam() and combination of policy and priority.
I guess you would use policies SCHED_FIFO, SCHED_RR where you can specify priority of thread.
For those who may be searching for BSD based OS solutions such as MacOS or iOS, you may want to consider setting the thread's priority using mach instead of the POSIX equivalent if necessary.
#include <mach/mach_init.h>
#include <mach/thread_policy.h>
#include <mach/sched.h>
#include <pthread.h>
int set_realtime(int period, int computation, int constraint) {
struct thread_time_constraint_policy ttcpolicy;
int ret;
thread_port_t threadport = pthread_mach_thread_np(pthread_self());
ttcpolicy.period=period; // HZ/160
ttcpolicy.computation=computation; // HZ/3300;
ttcpolicy.constraint=constraint; // HZ/2200;
ttcpolicy.preemptible=1;
if ((ret=thread_policy_set(threadport,
THREAD_TIME_CONSTRAINT_POLICY, (thread_policy_t)&ttcpolicy,
THREAD_TIME_CONSTRAINT_POLICY_COUNT)) != KERN_SUCCESS) {
fprintf(stderr, "set_realtime() failed.\n");
return 0;
}
return 1;
}
Source: https://developer.apple.com/library/content/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
Related
Look at this code:
#include <pthread.h>
#include <mutex>
int main()
{
std::mutex mtx;
pthread_mutex_t *native = mtx.native_handle();
}
Do libstdc++ or libc++ guarantee that the native_handle of a std::mutex is always a pthread_mutex_t* pointer? That would be nice because I can adjust the spin count of this std::mutex implementation with that.
Windows gives only a void* pointer for native_handle and I don't know its purpose. If I cast it to a CRITICAL_SECTION and call any Windows' own calls on it, I have a crash.
Does Windows return the handle used in the slow path synchronization across the kernel when there is contention?
If you want to future-proof your implementation, you can use overload resolution to dispatch between different native_handle types.
#include <mutex>
#ifndef WIN32
# include <pthread.h>
void tune_mutex(pthread_mutex_t* mutex)
{
// adjust spin-count
}
#endif
void tune_mutex(void*)
{
// Fallback for unknown types. Do nothing
}
int main()
{
std::mutex mutex;
tune_mutex(mutex.native_handle());
}
At least for GCC and Clang this should work. Also note that changing the return type would break the existing ABI (even if the standard allows it), so you can be reasonably sure that this won't change anytime soon. And I don't see a reason why it should change. People would want whatever improvements come to one mutex type also be present in the other.
For Windows, there is a note in the documentation
native_handle_type is defined as a Concurrency::critical_section* that's cast as void*
I guess mutex::lock() and mutex::unlock() arent backed by EnterCriticalSection() and LeaveCriticialSection under Windows.
I wrote this little program:
#include <Windows.h>
#include <iostream>
#include <mutex>
using namespace std;
int main()
{
CRITICAL_SECTION cs;
InitializeCriticalSection( &cs );
EnterCriticalSection( &cs );
LeaveCriticalSection( &cs );
mutex mtx;
for( size_t i = 100'000'000; i--; )
mtx.lock(),
mtx.unlock();
cout << "finished" << endl;
}
With the calls to EnterCriticalSection() and LeaveCriticalSection() I set two breakpoints on the DLL entry points of these functions. And both aren't hit in the loop. So I think std::mutex is implemented with the usual combination of an atomic variable and a binary semaphore under Windows.
I also tried to act on the native_handle() as it would have been a HANDLE by doing a WaitForSingleObject() on it. I immeadiately get a INVALID_HANDLE_VALUE on it, so it's for sure not a HANDLE.
But I thought something more in-depth about spinning: Spinning makes sense when a) the mutex is held only a very short time that spinning might succeed and b) when there's a extremely high locking and unlocking frequency across all cores. I think that's rather a rare case.
To my surprise, a C++11 std::thread object that has finished executing, but has not yet been joined is still considered an active thread of execution. This is illustrated in the following code example (built on Xubuntu 13.03 with g++ 4.7.3). Does anyone know if the C++11 standard provides a means to detect if a std::thread object is still actively running code?
#include <thread>
#include <chrono>
#include <iostream>
#include <pthread.h>
#include <functional>
int main() {
auto lambdaThread = std::thread([](){std::cout<<"Excuting lambda thread"<<std::endl;});
std::this_thread::sleep_for(std::chrono::milliseconds(250));
if(lambdaThread.joinable()) {
std::cout<<"Lambda thread has exited but is still joinable"<<std::endl;
lambdaThread.join();
}
return 0;
}
No, I don't think that this is possible. I would also try to think about your design and if such a check is really necessary, maybe you are looking for something like the interruptible threads from boost.
However, you can use std::async - which I would do anyway - and then rely on the features std::future provides you.
Namely, you can call std::future::wait_for with something like std::chrono::seconds(0). This gives you a zero-cost check and enables you to compare the std::future_status returned by wait_for.
auto f = std::async(foo);
...
auto status = f.wait_for(std::chrono::seconds(0));
if(status == std::future_status::timeout) {
// still computing
}
else if(status == std::future_status::ready) {
// finished computing
}
else {
// There is still std::future_status::defered
}
for what definition of "actively running code"? not that I know of, I'm not sure what state the thread is left in after it becomes joinable, in most cases I can think of you'd actually want fine grain control, like a flag set by the code running in that thread, anyway
for a platform specific solution, you could use GetThreadTimes
Is the PrintHello() function pthreads example thread-safe? I find these kind of examples online but I don't understand how they can be thread-safe. On the other hand, if I add a mutex around the code in PrintHello() function then the example would not be multithreaded as all threads would queue in wait for the previous thread to exit the PrintHello() function. Also, moving it to a class would not help as the member would have to be statically declared as pointers to non-static functions is not allowed with CreateThread() it seems. Any way of solving this?
#include <WinBase.h>
#include <stdio.h>
#include <stdlib.h> /* srand, rand */
#include <time.h> /* time */
#define NUM_THREADS 500
DWORD PrintHello(LPVOID oHdlRequest)
{
long tid;
tid = (long)GetCurrentThreadId();
/* randomly sleep between 1 and 10 seconds */
int sleepTime = rand() % 10 + 1;
sleep(sleepTime);
printf("Hello World! It's me, thread #%ld!\n", tid);
return 0;
}
int main (int argc, char *argv[])
{
/* initialize random seed: */
srand (time(NULL));
HANDLE threads[NUM_THREADS];
long t;
DWORD nThreadID;
for(t=0; t<NUM_THREADS; t++){
printf("In main: creating thread %ld\n", t);
threads[t] = CreateThread(
// Default security
NULL,
// Default stack size
0,
// Function to execute
(LPTHREAD_START_ROUTINE)&PrintHello,
// Thread argument
NULL,
// Start the new thread immediately
0,
// Thread Id
&nThreadID
);
if (!threads[t]){
printf("ERROR; return code from CreateThread() is %d\n", GetLastError());
exit(-1);
}
}
}
Since you're including WinBase.h, I'll assume that you're using MSVC. MSVC CRT has long supported multithreaded access - in fact, current versions of MSVC no longer support a single threaded CRT that isn't threadsafe. I believe that VS 2003 is the last version of MSVC that supported the single threaded CRT.
In the multithreaded CRT, functions are threadsafe and if they access global data internally they will synchronize among themselves. So each printf() executed in ProcessRequest() will be atomic with respect to other printf() calls in other threads (actually, the locks are based on streams, so the printf() calls will be atomic with respect to other CRT functions that use stdout).
The exceptions to this are if you use I/O functions that are explicitly documented to not take locks (so you can synchronize on them yourself for performance reasons), or if you define _CRT_DISABLE_PERFCRIT_LOCKS in which case the CRT assumes that all I/O will be performed on a single thread.
See http://msdn.microsoft.com/en-us/library/ms235505.aspx
POSIX makes similar guarantees that printf() will be threadsafe:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html
All functions that reference (FILE *) objects, except those with names ending in _unlocked, shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these (FILE *) objects.
http://newsgroups.derkeiler.com/Archive/Comp/comp.programming.threads/2009-06/msg00058.html (A post by David Butenhof):
POSIX/UNIX requires that printf() itself be atomic; it's not legal that two parallel calls to printf() from separate threads can mix their data. But those two writes may appear on the output in either order.
The code is not thread-safe in general; printf is not normally
reentrant. (An implementation could add reentrace to it as
an additional feature, but I don't know of any which do.) You
must add some sort of protection around it. (Under Windows,
a so called CriticalSection should be sufficient.)
You'll also have to find a thread safe alternative to sleep;
I can't find any documentation which says that it is reentrant
(and the Posix variant isn't), but Microsoft doesn't seem to
document reentrance in general. A classical solution for this
would be to create a Mutex, block it, and then call
WaitForSingleObject on it with the desired timeout;
CreateWaitableTimer and WaitForSingleObject should work as
well. (As I said, Microsoft's documentation is very deficient;
but WaitForSingleObject must be safe, since it is des igned to
be used when waiting for a mutex, among other things.)
Note too that unless you join the created threads, you'll
probably run off the end of main, and the process will
terminate before any of the threads will have run. (Under
Windows, you can use WaitForSingleObject or
WaitForMultipleObjects to join.)
An even better solution would be to the standard threads, if you
have a compiler which supports them, or Boost threds, if you
don't.
I'm trying to set core affinity (Thread #1 goes on first core, Thread #2 goes on second core, ...) while using std::thread in C++ 11.
I've already searched around various topics and on the internet and it seems C++ 11 API doesn't provide such low level feature.
On the other hand, pthreads come with pthread_setaffinity_np which would be useful if I could get the "pthread_t" value of my std::thread (I don't know if this is human reasonable or at least legitimate asking for it).
An example program of what I'd want to have in the end is this:
#include <thread>
#include <pthread.h>
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#define CORE_NO 8
using namespace std;
void run(int id) {
cout << "Hi! I'm thread " << id << endl;
// thread function goes here
}
int main() {
cpu_set_t cpu_set;
CPU_ZERO(&cpu_set);
for(int i=0; i<CORE_NO; i++)
CPU_SET(i, &cpu_set);
thread t1(run, 1);
// obtaining pthread_t from t1
/*
pthread_t this_tid = foo(t1);
pthread_setaffinity_np(this_tid, sizeof(cpu_set_t), &cpu_set);
*/
t1.join();
return 0;
}
I'd really prefer not to change the whole architecture of my project (which must provide such characteristic). I've now a massive use of std::thread but I can use pthread API in addition as well, as you have seen in the example.
Is there a way for me to solve this problem?
You can get the native handle for the thread with the native_handle function.
The example in the linked reference even uses this to call pthread functions.
I do not know if it is a suitable approach in your case, but what I usually do is to call the affinity primitives from within the thread. E.g., I place a snippet of code similar to this one somewhere at the beginning of the threaded function:
const int err = pthread_setaffinity_np(pthread_self(),...);
The call to pthread_self() will return the ID of the calling thread.
I am trying to create a thread in C++ (Win32) to run a simple method. I'm new to C++ threading, but very familiar with threading in C#. Here is some pseudo-code of what I am trying to do:
static void MyMethod(int data)
{
RunStuff(data);
}
void RunStuff(int data)
{
//long running operation here
}
I want to to call RunStuff from MyMethod without it blocking. What would be the simplest way of running RunStuff on a separate thread?
Edit: I should also mention that I want to keep dependencies to a minimum. (No MFC... etc)
#include <boost/thread.hpp>
static boost::thread runStuffThread;
static void MyMethod(int data)
{
runStuffThread = boost::thread(boost::bind(RunStuff, data));
}
// elsewhere...
runStuffThread.join(); //blocks
C++11 available with more recent compilers such as Visual Studio 2013 has threads as part of the language along with quite a few other nice bits and pieces such as lambdas.
The include file threads provides the thread class which is a set of templates. The thread functionality is in the std:: namespace. Some thread synchronization functions use std::this_thread as a namespace (see Why the std::this_thread namespace? for a bit of explanation).
The following console application example using Visual Studio 2013 demonstrates some of the thread functionality of C++11 including the use of a lambda (see What is a lambda expression in C++11?). Notice that the functions used for thread sleep, such as std::this_thread::sleep_for(), uses duration from std::chrono.
// threading.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include <chrono>
#include <thread>
#include <mutex>
int funThread(const char *pName, const int nTimes, std::mutex *myMutex)
{
// loop the specified number of times each time waiting a second.
// we are using this mutex, which is shared by the threads to
// synchronize and allow only one thread at a time to to output.
for (int i = 0; i < nTimes; i++) {
myMutex->lock();
std::cout << "thread " << pName << " i = " << i << std::endl;
// delay this thread that is running for a second.
// the this_thread construct allows us access to several different
// functions such as sleep_for() and yield(). we do the sleep
// before doing the unlock() to demo how the lock/unlock works.
std::this_thread::sleep_for(std::chrono::seconds(1));
myMutex->unlock();
std::this_thread::yield();
}
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
// create a mutex which we are going to use to synchronize output
// between the two threads.
std::mutex myMutex;
// create and start two threads each with a different name and a
// different number of iterations. we provide the mutex we are using
// to synchronize the two threads.
std::thread myThread1(funThread, "one", 5, &myMutex);
std::thread myThread2(funThread, "two", 15, &myMutex);
// wait for our two threads to finish.
myThread1.join();
myThread2.join();
auto fun = [](int x) {for (int i = 0; i < x; i++) { std::cout << "lambda thread " << i << std::endl; std::this_thread::sleep_for(std::chrono::seconds(1)); } };
// create a thread from the lambda above requesting three iterations.
std::thread xThread(fun, 3);
xThread.join();
return 0;
}
CreateThread (Win32) and AfxBeginThread (MFC) are two ways to do it.
Either way, your MyMethod signature would need to change a bit.
Edit: as noted in the comments and by other respondents, CreateThread can be bad.
_beginthread and _beginthreadex are the C runtime library functions, and according to the docs are equivalent to System::Threading::Thread::Start
Consider using the Win32 thread pool instead of spinning up new threads for work items. Spinning up new threads is wasteful - each thread gets 1 MB of reserved address space for its stack by default, runs the system's thread startup code, causes notifications to be delivered to nearly every DLL in your process, and creates another kernel object. Thread pools enable you to reuse threads for background tasks quickly and efficiently, and will grow or shrink based on how many tasks you submit. In general, consider spinning up dedicated threads for never-ending background tasks and use the threadpool for everything else.
Before Vista, you can use QueueUserWorkItem. On Vista, the new thread pool API's are more reliable and offer a few more advanced options. Each will cause your background code to start running on some thread pool thread.
// Vista
VOID CALLBACK MyWorkerFunction(PTP_CALLBACK_INSTANCE instance, PVOID context);
// Returns true on success.
TrySubmitThreadpoolCallback(MyWorkerFunction, context, NULL);
// Pre-Vista
DWORD WINAPI MyWorkerFunction(PVOID context);
// Returns true on success
QueueUserWorkItem(MyWorkerFunction, context, WT_EXECUTEDEFAULT);
Simple threading in C++ is a contradiction in terms!
Check out boost threads for the closest thing to a simple approach available today.
For a minimal answer (which will not actually provide you with all the things you need for synchronization, but answers your question literally) see:
http://msdn.microsoft.com/en-us/library/kdzttdcb(VS.80).aspx
Also static means something different in C++.
Is this safe:
unsigned __stdcall myThread(void *ArgList) {
//Do stuff here
}
_beginthread(myThread, 0, &data);
Do I need to do anything to release the memory (like CloseHandle) after this call?
Another alternative is pthreads - they work on both windows and linux!
CreateThread (Win32) and AfxBeginThread (MFC) are two ways to do it.
Be careful to use _beginthread if you need to use the C run-time library (CRT) though.
For win32 only and without additional libraries you can use
CreateThread function
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx
If you really don't want to use third party libs (I would recommend boost::thread as explained in the other anwsers), you need to use the Win32API:
static void MyMethod(int data)
{
int data = 3;
HANDLE hThread = ::CreateThread(NULL,
0,
&RunStuff,
reinterpret_cast<LPVOID>(data),
0,
NULL);
// you can do whatever you want here
::WaitForSingleObject(hThread, INFINITE);
::CloseHandle(hThread);
}
static DWORD WINAPI RunStuff(LPVOID param)
{
int data = reinterpret_cast<int>(param);
//long running operation here
return 0;
}
There exists many open-source cross-platform C++ threading libraries you could use:
Among them are:
Qt
Intel
TBB Boost thread
The way you describe it, I think either Intel TBB or Boost thread will be fine.
Intel TBB example:
class RunStuff
{
public:
// TBB mandates that you supply () operator
void operator ()()
{
// long running operation here
}
};
// Here's sample code to instantiate it
#include <tbb/tbb_thread.h>
tbb::tbb_thread my_thread(RunStuff);
Boost thread example:
http://www.ddj.com/cpp/211600441
Qt example:
http://doc.trolltech.com/4.4/threads-waitconditions-waitconditions-cpp.html
(I dont think this suits your needs, but just included here for completeness; you have to inherit QThread, implement void run(), and call QThread::start()):
If you only program on Windows and dont care about crossplatform, perhaps you could use Windows thread directly:
http://www.codersource.net/win32_multithreading.html