Sometimes I read about (if I'm not interpreting wrong) that posix threads are not available or valid on sone platforms such as some RTOSs which inplements their own threading mechanism.
So, is posix thread can be considered as standard (at least on general purpose OS)? And is it platform independent?
"So, is posix thread can be considered as standard (at least on general purpose OS)?"
No, it's not standard for OS's that POSIX threads are supported.
I'd say that std::thread implementations rely on some POSIX thread commonly defined features.
Embedded Linux platforms are POSIX compatible of course, and you can rely on pthreads.
Windows platforms (counting as a general purpose OS) for instance, doesn't support POSIX threads natively, but there are wrapper APIs available with e.g. MinGW or cygwin.
"that posix threads are not available or valid on sone platforms such as some RTOSs which inplements their own threading mechanism."
Other embedded platforms like FreeRTOS don't support that threading model directly, but are eligible to write a POSIX wrapper.
The basic thread semantics could be usually wrapped well for the POSIX standard requirements, and injected to newlib or whatever you like to use as binding for realising the standards implementation.
POSIX, the standard that specifies pthread, is a standard (Actually, more a group of standards) defining operating system behavior and functions. An OS either implements the standard or it doesn't. The goal of POSIX is platform independence, all the same OS calls on all platforms, but as with all standards, folks bolts stuff onto the edges to get extra functionality that is not portable or leave stuff out when it becomes problematic.
Linux implements POSIX fairly closely (but not even all families of Linux agree on how closely) so your concern will be with compatibility edge cases that I hope will be well documented at this point.
Windows POSIX support is somewhere below weak so you cannot count on it on general purpose OSes.
I recommend a quick search here on SO, Google or giving Wikipedia a look-over for a better description of POSIX.
Related
Suppose you are developing two application (A and B).
How can you send some piece of information to B from A if you are only allowed to work at the c++ language level (that is including the standard libraries and STL) ?
Now Im thinking std::ofstream and std::ifstream could be a possible solution (albeit a crude one) ? - but what pitfalls is there and can they be avoided ? (how?).
You just cannot. Standard C++17 does not know about any kind of inter-process communication and does not know much about processes (except thru std::system whose behavior is not really specified). Some operating systems don't have any processes and some of them don't have files and some of them don't have pipes.
Read more about operating systems. I strongly recommend Operating Systems: Three Easy Pieces (which is freely available).
Of course, you can read and write a file, but the synchronization between the two processes should still happen (perhaps by running one after the other, in some operating system specific way, so running A then B, and how that exactly happens is OS specific)
Read that C++17 standard (e.g. the draft here) to check.
Some C++17 implementations might not even have any notion of process. You could have a fully compliant C++17 on some embedded system without any operating system dealing with processes.
My recommendation is to be pragmatical, and use some framework like Boost, Qt, ZeroMQ, or POCO (or old Berkeley sockets) which deals with processes and inter-process communication facilities; you'll likely to find a framework supporting the several OSes you really care about (AFAIK, all of Boost, POCO, Qt know about Linux, Windows, MacOSX and offer a common API abstracting them; but you could find some academic operating system which is incompatible with them; in practice, any framework targeting both Windows and POSIX should be practically enough).
With some curiosity, you may find an OS with a good C++17 implementation which has a very weird API (look into GNU Hurd for an example).
If your IPC facility is based on byte streams, look into text-based protocols (perhaps JSONRPC, SOAP, HTTP, ...). They are easier to code and most of them come with some C++ compatible library...
And with a few months of work and a lot of know how, you might even port a recent GCC or Clang to most other operating systems: they are careful to abstract the requirements on the OS in a clever way.
Remember, you could find OSes which don't even have any file system: look into CapROS or Contiki for some recent example, and look also inside tunes.org where interesting discussions related to your topic, in the past century, have been archived. But with some pain (my guess is a few months of work for a GCC or Clang expert), you'll be able to port a recent GCC or Clang to target it to obtain a C++17 cross-compiler targetting them.
IMHO, a C++ standard library which enables only to "open" one single "file" (supposedly named THEFILE) is conforming to the letter of the C++17 standard. AFAIK, you don't have any guarantee that std::ifstream or std::ofstream works successfully.
BTW, current processors are practically multi-core, so it makes a lot of sense to try running A and B in parallel and doing some IPC (in an OS specific way, perhaps abstracted by some framework or library).
When implementing condition variables into a Win32 C++ program, would it be better to use Win32 functions, classes, and data types (e.g. CreateThread, SleepConditionVariableCS, WaitForSingleObjectEx, ReleaseMutex, CONDITION_VARIABLE) or those from the C++11 standard libraries (e.g. thread, wait, join, unlock, condition_variable)?
Since the answer to this question is probably not binary, what considerations should one take into account when making such a decision?
The C++ synchronization mechanisms are designed to C++ principles. They free their resources in the destructor, and they also use RAII to ensure safe locking. They use exceptions to signal errors.
Essentially, they are much harder to use incorrectly than the function-based native Windows API. This means that if you can use them (your implementation supports them), you always should use them.
Oh, and they are cross-platform.
One consideration should be what your compiler can handle. For example, when you install MinGW on Windows, you can choose whether to install the API for POSIX threads or Win32 threads. On the other hand, if you use TDM-GCC, you should be aware that versions 4.7.1 and lower use Win32 threads, while versions 4.8.1 and higher use POSIX threads. And as woolstar mentioned above, if you're using Microsoft's compiler, you should check to see whether the bugs in its support for these classes have been worked out.
If your compiler supports POSIX threads, you can use the C++ thread classes of the Standard Library (e.g. thread, mutex, condition_variable). If your compiler supports Win32 threads, you can use the Win32 thread functions.
In my case, I originally had TDM-GCC 4.7.1 and tried to use the C++ Standard Library classes, but that didn't work (for reasons explained above). So I installed MinGW by itself and chose "posix" in the "threads" option of the installer. Then I was able to use those classes.
I am using C++ with boost on Linux.
What is the best way to prioritize a thread based on work type?
Is it possible to vary a thread priority in POSIX / pthread / Linux?
As far as I know boost doesn't provide an API to do it (the C++11 standard certainly doesn't at least).
On Linux, you can nice or setpriority each thread independently from the others. Note however that this is not POSIX-conformant:
According to POSIX, the nice value is a per-process setting. However, under the current Linux/NPTL implementation of POSIX threads, the nice value is a per-thread attribute: different threads in the same process can have different nice values. Portable applications should avoid relying on the Linux behavior, which may be made standards conformant in the future.
Since Linux uses pthreads (and so does the Linux port of boost) you could also use pthread_setschedparam which has the advantage of being more portable than the Linux-specific per-thread nice behaviour.
In both cases, there's the slight uneasiness due to having to resort to system facilities in order to manage supposedly "opaque" boost (or std in C++11) resources, so tread carefully (as with anything implementation-specific).
I have searched hard but still confused why POSIX is called "Portable Operating System Interface", what I learned is that it is some threading library for Unix environment, because when you need to use it under windows you have to use cygwin or "Windows Services of Unix", etc. That's why I am confused why it is called Portable OSIX. I am a professional C/C++ programmer in Windows domain but new in Unix/Linux. Thanks for your answers in advance.
Before Posix, the Unix family tree was becoming very diverse and incompatible. A program written for one Unix was not compatible with a different Unix without significant porting effort.
Posix was one of the attempts to present a common set of utilities and programming interfaces so that your software would be portable to multiple versions of Unix.
Since Posix is about the interface and not the actual OS, it is possible to have a Posix facade on a non Unix OS (such as the Microsoft Windows Services for Unix presenting a Posix facade on top of Windows).
That one or two stragglers have decided to not make it part of their core doesn't not make it any less portable to almost every other important operating system.
POSIX is simply an interface for operating systems that defines concepts like threads, processes, signals, pipes and I/O. This is not the only interface that's portable across multiple interfaces, but is simply one standard. The name was actually defined by Richard Stallman in the 1980s.
The reason for defining POSIX was that many different versions of UNIX were incompatible, because operating systems hadn't agreed on the implementation of threading or processes.
Here are some more links for further research:
The History of Posix: A Study in the Standards Process
POSIX (Wikipedia)
POSIX defines a set of portable C functions, shell, programs that make the life of a programmer easier because given the definitions in POSIX, it is much more easier to write portable code (not just C, but shell scripts too). Imagine if everyone had their own way of doing things!
Not all the operating systems are POSIX compliant, so if you have to develop for those too, you have to do system-specific things. But POSIX is probably the portable standard across different kinds of systems today. Sure, there is ISO C, which is more portable, but then it's hard to write very useful programs in just ISO C!
Is there a portable way of getting thread and/or process identifier (string, int, ...) with C++?
You have a few ways, but all imply the use of an external library abstracting the thread for you.
Among the popular choices, two are:
The Boost.Thread library. This is the most portable but imply working with Boost, which is a HUGE library
The Qt library. This is less portable and imply to work with Qt, a big library.
If you already use any on these two libraries, I would recommend sticking with it. Otherwise, look at what other tools they provide and make a choice.
There is no portable way when portable means a way that works on every platform for that a C++ compiler exists. Such a way had to be part of the C++ standard, in which case it really would work everywhere (just like the other parts of the C++ standard work everywhere). Everything not in the standard is not guaranteed to work on any platform, unless the platform states to support this standard.
Every solution people have suggested here is a solution that uses an external library and thus can only work on platforms supported by that library; and no library is available for every existing platform.
Probably the one that will get you farthest is POSIX, after all every UNIX like system tries to support at least some POSIX (the more the better), very little can call themselves really being 100% POSIX-compliant platforms (e.g. A/UX, AIX, HP-UX, IRIX, Mac OS X 10.5, MINIX, QNX, Solaris, UnixWare, VxWorks, ... to name a few, there are more of course). However, there are quite a couple of platforms that offer at least some POSIX support, some more, some less and some are almost POSIX-compliant (e.g. FreeBSD, Linux, NetBSD, BeOS, OpenBSD, ... and others).
Windows is unfortunately far away from being one. NT used to be partly POSIX conform, but now it has more or less vanished (Win2000/20003, WinXP, and Vista can still be set into a POSIX emulating mode, translating some POSIX call to internal API calls by installing Microsoft Windows Services for UNIX - SFU 3.5 or higher), however there are ways to get some POSIX functionality on Windows through external libraries as well (Cygwin offers LGPL libraries you can link with your app to enable a fair amount of POSIX functions on Windows).
The advantage of POSIX is not only that it is relatively widespread, but also that it is standardized and you can easily look up the standard on the Internet. Using POSIX calls you can get a thread id and a process id.
I always thought threads were external from C++. In Java, there's a native thread built-in to the language.
You'd have to find a portable thread library.
The only way is to use portable library. Id recommend Qt (it doesn't have to be GUI app) or maybe wxWidgets. If you are developing a game check out SDL
Also check out boost libs they might have something.
You may also use part of ACE library, which implements a platform independent wrapper. Finding PID would be one of the files in the library (maybe ACE_Process/ ACE_Thread).
I'm not sure how portable they are but Posix threads may be another option you want consider. See also here. I agree with Steve's comment--portable to which platforms?
getpid() is a portable way to get the process ID.
I don't think you're going to find a portable method unless it is through a wrapper library. Each threading system (eg. Windows, or POSIX) are going to have their own mechanism.