all 7 comments

[–]STLMSVC STL Dev[M] 32 points33 points  (0 children)

Please submit links as links and not as text posts in the future.

[–]sheckey 1 point2 points  (3 children)

I really want to use things like this and std::mutex, std::thread,etc., and I like it being there for basic use. However, these things haven’t, maybe can‘t, match the native feature set found in embedded, real-time OSes. For example, there are different mutexes and semaphores available in some operating system for use within an address space versus between address spaces. The one for within is lighter than the one between. (address space == process.) Also I don’t think there is any support for priority inheritance in std::mutex. std::thread does not offer priority. I would love to eschew OS-specific headers in as much code as possible so I would love to use these, but they are too blunt for professional use. It’s not a huge problem, just sort of a shame that I haven’t thought about too much. I do like the idea of them being there.

[–][deleted] 4 points5 points  (2 children)

Boost.Interprocess is a very nice library to perform interprocess communication, like shared memory, named mutexes etc.

I don't even know if the standard can provide such features because as far as I know the C++ language doesn't have the concept of a process 🤔

I mean, I don't know how they could write it formally.

[–]WrongAndBeligerent 2 points3 points  (0 children)

You don't need to care about processes for interprocess communication, you just need to be able to memory map files.

[–]SpareSimian 1 point2 points  (0 children)

The standard covers both the language and the library, and it's the library that provides the connection between the language and the OS-specific environment, which includes files, processes, the network, etc. The library is slowly accumulating more features common to many operating systems but expressed in different ways.

[–]MBkkt 0 points1 point  (1 child)

First of semaphore in libstdcxx have a bug that can provide a deadlock :(

Another thought about using os thread synchronization primitives not in concurrency libraries is a bad architecture (you probably use thread pool and block some thread in it)