The reason your code is shorter is that it is broken. I tried to explain that to you. Try running the stdlib wait group tests against your code. They will fail.
> On May 4, 2019, at 4:22 PM, Louki Sumirniy <louki.sumirniy.stal...@gmail.com> > wrote: > > Those who follow some of my posts here might know that I was discussing the > subject of channels and waitgroups recently, and I wrote a very slim and > simple waitgroup that works purely with a channel. > > Note that it is only one channel it requires, at first I had a ready and done > channel, but found a way to use nil and close to replace the ready and done > signals for the main thread. Here is the link to it: > > https://git.parallelcoin.io/dev/9/src/branch/dev/pkg/util/chanwg/waitgroup.go > > For comparison, here is the code in the sync library: > > https://golang.org/src/sync/waitgroup.go > > The first thing you will notice is that it is a LOT shorter. It does not make > use of the race library, though I can see how that would allow me to allow > callers to inspect the worker count, a function I tried to add but made races > no matter which way the data fed out (even when copying it in the critical > section there in the New function. > > It is not racy if it is used exactly the way the API presents itself. > > I haven't written a comparison benchmark to evaluate the differences in > overhead between the two yet, but it seems to me that almost certainly my > code is at least not any heavier in size and thus cache burden, and unless > all those extra things relating to handling unsafafe pointers and race > library are a lot more svelte code than they look, I'd guess that maybe even > my waitgroup is lower overhead. But of course such guesses are worthless if > microseconds are at stake. So I should really write a benchmark in the test. > > The one last thing is that I avoid the need for use of atomic by using a > concurrent replicated datatype design for the increment/decrement, which is > not order-sensitive, given the same set of inputs, it makes no difference > what order they are received, at the end the total will be the same. Ah yes, > they are called Commutable Replicated Data Types. > > This isn't a distributed system, but the order sensitivity of concurrent > computations is the same problem no matter what pipes the messages pass > through. This datatype is perfectly applicable in distributed as concurrent, > in this type of use case. > > I just wanted to present it here and any comments about it are most welcome. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
