3 ms·
How does this compare with: * Using std::atomic<T> ? https://en.cppreference.com/w/cpp/atomic/atomic https://en.cppreference.com/w/cpp/atomic/atomic * folly::
by einpoklum 4y ago
How does this compare with:
* Using std::atomic<T> ? https://en.cppreference.com/w/cpp/atomic/atomic https://en.cppreference.com/w/cpp/atomic/atomic
* folly::Synchronized, mentioned by ot57? https://github.com/facebook/folly/blob/main/folly/docs/Synchronized.md https://github.com/facebook/folly/blob/main/folly/docs/Synch...
* Boost synchronized data structures, -mentioned by mchicken 53? https://www.boost.org/doc/libs/1_81_0/doc/html/thread/sds.html https://www.boost.org/doc/libs/1_81_0/doc/html/thread/sds.ht...
?
... it looks like the SerenityOS people developed this without considering the C++ ecosystem of today.
- gpderetta 4y agostd::atomic really has different use cases. It is meant to be used for objects that can be modified via atomic RMW primitives and require T to be trivially copyable. While you can in principle implement arbitrary operations on top of those RMWs, it might not be the best fit. For large Ts, is indeed implemented using a mutex or, more likely, a lock pool, so I guess if you squint hard enough it can be considered related.
- MontagFTB 4y agoMy understanding is that Serenity has a philosophy of not using dependencies outside of itself. Perhaps this type drew from external inspiration, but was ultimately written in light of that philosophy?
- loeg 4y agoWell, std::atomic is wholly unrelated. MutexProtected seems fundamentally similar to boost and folly synchronized objects, just without the ergonomics and battle-testing the other major libraries have already gotten.