6 ms·
So many threading primitives have different names on different platforms. This is basically Go's WaitGroup, except the C++ latch can't be incremented (it's othe
by klodolph 5y ago
So many threading primitives have different names on different platforms. This is basically Go's WaitGroup, except the C++ latch can't be incremented (it's otherwise identical). I wonder why that is?
- junon 5y agoUsually such guarantees allow the implementation to use something other than atomics (e.g. memory barriers) for avoiding data races, which are more performant and can avoid contention/context switching/spinning. I too would love to know the specific reasoning though.
- vinkelhake 5y agoIt's CountDownLatch in Java.
- brundolf 5y agoCue the jokes about Java name length
- skocznymroczny 5y agoI like these names. Maybe it's a pain if you're using something like vim to program, but in a typical Java IDE or VSCode you'd just write CDL, ctrl+space, enter.
- signa11 5y agonot that per-se, but is there a CountUpLatch(...) as well ;)
- dgellow 5y agoThere is always std::barrier: https://en.cppreference.com/w/cpp/thread/barrier https://en.cppreference.com/w/cpp/thread/barrier. The C++ stdlib terminology is always so weird.
- jcelerier 5y agoDiscussion on naming from a few months ago : https://news.ycombinator.com/item?id=25902827 https://news.ycombinator.com/item?id=25902827
- Glavnokoman 5y agoYep. C++ is not good at naming things somehow. But bringing up Golang in a discussion about naming is just ridiculous. Unless you want to show that C++ is not actually the worst.
- zambal 5y agoTo me, the parent poster didn't imply that golang's naming is better, they just wondered why there's a lack of naming conventions regarding threading in general.
- Glavnokoman 5y agoAh! Thanks! You're right. I did not read it this way...
- lenkite 5y agoLatch is actually the standard name for this concurrency construct.
- msk-lywenn 5y agoIs go worst than rust at naming? It took me a while to get used to Cow and Arc... (not to mention "fn" which to me will always be the french far right political party)
- iudqnolq 5y agoI like that Rust has optimized certain bits for ease of intermediate use. Sure those could be EitherOwnedOrBorrowed and AtomicReferenceCountedPointer, but that'd be annoying to type once you know them. They're also not hard to remember if you learn the acronyms (for me, at least).
- andrekandre 5y agoEitherOwnedOrBorrowed and AtomicReferenceCountedPointer, but that'd be annoying to type once you know them. code is read more than it is written, so having those longer terms helps with reducing mental load and providing self-documenting code and with most modern ide or even text editors providing autocompletion, (imho) i think abbreviations not really neccessary (though they can be fun in the case of kotlin ^^)
- signa11 5y ago/// ---------------------------------------------------------------------------- /// latches are great for multi-threaded tests with following sequence of steps /// 1. setup test data /// 2. create a latch /// 3. create test threads each decrementing the latch-count /// 4. when all threads have reached the latch, they are unblocked. /// /// sligtly verbose commented code to illustrate this void foo() { /// -------------------------------------------------------------------- /// create a latch with non-zero-count unsigned const thread_count=...; std::latch done(thread_count); my_data data[thread_count]; std::vector<std::jthread> threads; /// -------------------------------------------------------------------- /// threads decrement count as they are created for(unsigned i=0;i<thread_count;++i) threads.push_back(std::jthread([&,i]{ data[i]=make_data(i); done.count_down(); do_more_stuff(); })); /// -------------------------------------------------------------------- /// others wait for latch to be signalled, when the count reaches zero, /// latch is permanently signalled, and threads are woken done.wait(); process_data(); } have fun ?
- klodolph 5y agoI'm just saying in Go, the equivalent construct (WaitGroup) does not require you to figure out the count ahead of time. There's an idiom of: var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() }() wg.Wait() The middle part of the block can be done freely, you don't have to count the threads beforehand.
- gpderetta 5y agoLikely minimalism. It can be implemented more efficiently if it can only count down. It is a low lever synchronization primitive, you can build more complex stuff on top of it.
- Koshkin 5y agoMore likely, due to the tendency to support pre-existing patterns, no matter the redundancy.