I'm looking for the pthreads standard for some work I'm doing on parallelism. I have found that it is supposed to be IEEE 1003.1c "EEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)". However, when I get to it, it says that the standard has been "superseded", but they don't say by what (or I failed to see where they do say it). Does anyone know of the link to the superseding standard? Thanks.
It's been superseded by a newer edition (2008). It's available as IEEE 1003.1-2008 or ISO/IEC 9945-2009 (for enough money) or The Open Group Single Unix Specification, version 7 (for free). All three have identical content.
Yes, that's a very old document. What you probably want is the full POSIX 2008 spec.
Since you tagged Linux in your question, I recommend that in addition to what Jerry Coffin answered, you look at the Linux pthreads man page. The current Linux pthreads implementation (NPTL) is not exactly POSIX conformant; there are small details that are handled differently.
There are also extensions like the __thread keyword (to designate per-thread variables, much simpler than pthread_key_create(); explained in detail for GCC here) that are available in Linux and other operating systems, and are likely to be included in POSIX at some point in the future.
If you are doing extremely performance-sensitive work, I recommend you also look at the atomic built-ins and vector extensions available in GCC, ICC, and Pathscale compilers (GCC vector extensions, legacy __sync builtins, C++11-style __atomic builtins, and x86-specific builtins). While these are not standardized yet, they are available in aforementioned compilers, and aside from the recent __atomic builtins, have been available for at least a decade. From personal experience, I can attest that these facilities can provide a significant performance boost (~40% in a classical molecular dynamics simulator I'm working on), while still being portable between non-Windows systems and compilers.
Related
One of the Units of Functionality that POSIX states an OS needs to provide to be POSIX compliant is POSIX_C_LANG_SUPPORT. Basically this is the whole C Standard Library with some more things.
My question is simple: developers of POSIX compliant OSes usually just download an open source version of C Standard Library (e.g. glib or uClibc) and adapt it to fit POSIX or they implement everything from scratch? Is there any advantage in rewriting the C Library instead of just picking one of the very known implementations and adjust it to my needs?
Really, it is done in the inverse way.
We have different Unix versions: two main families: SystemV and BSD, different manufacturers, and so there was a need to standardize. US government wanted also standardized programs, so POSIX (version 1) was created, by standardizing OS interfaces (a step further than just C standard).
Windows NT is also POSIX (version 1) compatible, just because government wanted standardized tools. So POSIX was designed very very broad.
Then with time, there were need to standardize some more Unix (and similar) systems. Not as just one system, one API, but as common API, and so programs (e.g. GUI libraries or databases) could eventually use extension, but also make sure that program that follow the standard works on compatible system.
This was SUS (Single Unix Specification). This required a UNIX like system (unlike POSIX 1).
Then POSIX became not so important: application that in theory could work on all POSIX systems didn't really work on POSIX Windows.
So the new version of POSIX merged old POSIX plus SUS plus new useful function missing in SUS.
Now Linux is important, so Linux implementations (e.g. glibc) is taken into account when updating POSIX. You will see in the mailing list, that POSIX is defined by "vendors" of different Unix and similar systems.
So, it is not that operating systems extend POSIX, it is just that POSIX takes the most useful and standard options from different OS. It creates new interfaces just when existing interfaces are so incompatible, that by standardizing, it will break existing programs.
For the "second" question: when you develop a new operating system, you choose what way to go. Usually it is just derivation and fork (and distributions): again from the two Unix families, of just deriving Linuxes from RedHat or Debian). Sometime system is build from scratch, because of the design. Kernel provides most of system calls, so e.g. glibc needs a lot of systemcall (given by kernel) implemented in a similar way as POSIX. Glibc is not complete. Note: early Linux distributions used other libraries. GLibc was also written from scratch.
Well, we are all dwarves standing on the shoulders of giants.
Writing a new OS is a huge undertaking, so the wise one will re-use whatever (design, libraries, compilers, other software) they can. It's still in all likelyhood far too much work, so why make it even harder by rewriting everything from scratch?
I was wondering whether anybody here could help me better understand the relationship between OSX and C. There's some developer information related to C++ in xcode but nothing for C.
I believe one fundamental difference is that osx uses libc as opposed to glibc. Can anybody point me to libc documentation? I can't seem to find any.
I've seen the usr/includes folder but all that does is make me wonder where I can get a reference that elucidates all the options available to me. For instance, I just discovered <tree.h>. That's all well and good but is there any documentation? Or do I need to trawl the includes folder?
It seems that you're asking whether the functionality that OSX provides to you as a programmer is partially different from other *nix systems; focusing on the functionality that OSX's implementation of the C Standard Library provides you with.
Now keep in mind that while the C Standard Library is a very common way to take advantage of the functionality the operating system kernel exposes, it's not the only way. You can use other low-level libraries, or write low-level functions yourself.
Having said that, consider the following:
OSX, like many other *nix systems, is "mostly POSIX-compliant". Meaning that its particular C Standard Library implementation will likely expose headers defined by the POSIX standard. This is the stuff you can rely on regardless of whether you use libc, glibc, or some other implementation of the C Standard Library.
Depending on the particular C Standard Library you're using, it might come with additional functionality, like BSD libc - we say "superset of the POSIX Standard Library" to that. While it can contain implementations of things specific to BSD (and therefore OSX), it mostly seems to contain things that can be implemented regardless of the operating system flavour. For example, the sys/tree.h header that you mention is "an implementation of Red-black tree and Splay tree" - by no means something that couldn't have been implemented on a Linux system!
To sum up:
OSX comes with an implementation of the C Standard Library called BSD libc that provides some additional headers on top of what the POSIX Standard defines.
The difference in functionality between the XNU kernel used by OSX and other *nix kernels will not necessarily be captured in the difference between the C Standard Library implementations. If you want to know what the XNU kernel can do for you that the Linux kernel can't, the place to start is with the kernels themselves.
So your question can be split into:
What is the difference between glibc and BSD libc?
and
What is the difference between the XNU kernel and the Linux kernel?
It's a bit unclear what you're asking.
OS X is based on top of FreeBSD, a POSIX-compliant UNIX operating system. The relationship between OS X and C is that C is one of many programming languages that you can code in to develop for the platform (C is the core of Objective-C, an otherwise unused language that Apple champions).
OS X doesn't use libc. clang, the compiler that ships as part of Apple's developer tools package for OS X, uses libc. There's a difference. If you want to use glib, grab GCC from Homebrew or Macports and use it to compile your programs instead of clang.
Lastly, you can't find documentation for libc, as all C libraries, like libc, glibc, etc, all provide the same set of functions if they are standards-compliant. There tend to be few differences end-user-wise between the different C libraries; so, if you want to find out about a header file, use man, like this: man clang to read clang documentation, for example.
Hope this helps.
I'm writing an OS that should run on a variety of SoCs (e.g: Xilinx Zync, Freescale QorIQ).
My problem, not all of the provided IDEs (given by Xilinx, Freescale, etc.) provide the same libraries (standard C & POSIX libraries).
For instance, the CodeWarrior IDE has the timespec structure, while Xilinx's doesn't.
Also, sleep is implemented in some of the provided libs, but I have my own implementation.
I want my code to be independent of the compiler (some manufacturers provide more than one IDE and with a different compiler).
Any suggestions?
My suggestion: Code to POSIX standards. Where the vendor library falls short of POSIX, implement a POSIX layer yourself.
Leave the core OS generally #ifdef-free, and put the mess in a conditionally-compiled compatibility layer.
The simple (though longer-to-implement) solution is to not depend on the library provided by the vendor. Write your own library. Probably this can be done with a little bit of layering. All of them provide strlen(), for example.
I am quite a newbie to c programming. Until now i only found pthread_mutex_lock can make the code region run only by one thread. Does there are any other ways to implement a lock? Or every other way to do a lock is still use pthread_mutex_lock function?
Threads were only introduced into the ISO C standard with C11, a rather recent edition to the standard so not necessarily widely supported yet.
You need to look into threads.h and the mtx_* functions for an understanding of that.
Before then, pthreads was probably your best bet with its wide implementation although, not being standard C (a), its support wasn't mandated.
For example, Windows has its own way of doing threading, using functions like CreateThread.
However, there are various third-party products such as pthreads-win32 that aim to give pthreads support to Windows, to assist in porting of applications from POSIX-compliant operating systems.
(a) It is a POSIX standard (part of IEEE 1003.1) so that may be good enough for some people.
There is no way to lock in the c language. Operating systems might provide support for locking (without regard for the language), and libraries such as pthreads can take advantage of operating system services, however this is beside the language. (By contast, other languages have native locking built into them, such as through Java's synchronized keyword.)
Is there a C library available for operations such as file operations, getting system information and the like which is generic, which can be used when compiled in different platforms and which behaves in a similar way?
Edit: Something like Java or .NET platform abstracting the hardware.
Have you tried the standard library? It should be implemented on any system that has an ISO compliant C runtime.
Yes; the ISO Standard C library. It may not cover all the functionality you want, but that is exactly because it is generic, and as such is also lowest common denominator. It only supports features that can reasonably be expected to exist on most hardware, including embedded systems.
The way to approach this is perhaps to specify the range of target platforms you need to support, and then the application domains (e.g. GUI, networking, multi-threading, image processing, file handling etc.), and then select the individual cross-platform libraries that suit your needs. There is probably no one library to fulfil all your needs, and in some cases no common library at all.
That said, you will always be better served in this respect by embracing C++ where you can use any C library as well as C++ libraries. Not only is the C++ standard library larger, but libraries such as Boost, wxWidgets, ACE cover a broader domain spectrum too. Another approach is to use a cross-platform language such as Java, which solves the problem by abstracting the hardware to a virtual machine. Similarly .NET/Mono and C# may provide a solution for suitably limited set of target platforms.
Added following comment:
Hardware abstraction in a real-machine targeted language (as opposed to a VM language such as Java or CLR based languages) is provided by the operating system, so what you perhaps need is a common operating system API. POSIX is probably the closest you will get to that, being supported on Linux, Unix, OSX (which is Unix), QNX, VxWorks, BeOS and many others; but not importantly Windows. One way of using POSIX on Windows is to use Cygwin. Another is to use a VM to host a POSIX OS such as Linux.
For anything not found in the standard library, GLib is a good first place to look along with other libraries built to interact with it. It offers for example threads, mutexes and IPC that you won't be able to write portably using plain standard libraries, and you can use many more GNU libraries that follow the same conventions up to a full GUI in GTK+. GLib supports the usual popular operating systems.
If the C standard library is not sufficient for your needs, a minimal hyperportable subset of POSIX might be the target you want to code to. For example, the main non-POSIX operating system Windows still has a number of functions with the same names as POSIX functions which behave reasonably closely - open, read, write, etc.
Documenting what exactly a "hyperportable subset of POSIX" includes, and which non-POSIX operating systems would conform to such a subset, is a moderately difficult task, which would be quite useful in and of itself for the sake of avoiding the plague of "MyCompanyName portable runtime" products which appear again and again every few years and unnecessarily bloat popular software like Firefox and Apache.
If you need facilities beyond what the Standard C library provides, take a look at the Apache Portable Runtime (APR). You should also review whether POSIX provides the functionality you are after, though that comes with its own bag of worms.
If you want to get into graphics and the like, then you are into a different world - GTK, Glib and Qt spring to mind, though I've not used any of them.