Hello Gaurav.
You might want to look at Jon Gjengset's project:
https://github.com/jonhoo/drwmutex
Also, I seem to recall Dmitry saying that sync.Pool distributes locking. So it
might be worth looking into.
Another type of lock which might be of interest is MCS (or K42, CLH, HCLH).
John
John Souvestre - New Orleans LA
-----Original Message-----
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Ian Lance Taylor
Sent: 2016 August 14, Sun 14:21
To: Gaurav Agarwal
Cc: golang-nuts
Subject: Re: [go-nuts] Fast ConcurrentCounter without memory sharing
On Sun, Aug 14, 2016 at 9:58 AM, Gaurav Agarwal
<gauravagarw...@gmail.com> wrote:
> Ian, thanks for the explanation and the link !
>
> But I am still unclear how to implement such a concurrent counter in Go -
> given that we can't find out what thread/cpu is the goroutine executing.
> Note that in this case there was never the need of pinning a goroutine to a
> thread or cpu; just that we wanted to know which is it, at any given moment
> so as to access the required memory location.
>
> Do you have any alternate ideas for this?
I think the last time a similar though not identical concept was
discussed was this thread:
https://groups.google.com/d/msg/golang-nuts/zt_CQssHw4M/TteNG44geaEJ
It would be interesting to know what the potential speedup is. It
should be easy enough to write a C program to measure that. But when
writing such a program, remember that no real program will simply
increment a concurrent counter. The question is not just how much
speedup you can get from a concurrent counter, but how much it will
matter to a real program.
Anyhow, that aside, if you know how many goroutines you are going to
run, just allocate a slice with that many elements. If you don't, use
a set of fixed size arrays and have each goroutine grab a pointer to a
possibly-new array when it starts. Pass down the pointer.
If these approaches seem awkward, I suppose you could get
syscall(syscall.GETCPU, ...) when you want to increment a counter.
But that would admittedly introduce overhead that would distort the
results.
We do not plan to modify the Go runtime to expose a thread or CPU ID,
because although it's true that your application doesn't care much if
the value becomes immediately stale, other applications would care.
It seems unwise to expose a value that is extremely easy to misuse in
a way that will often succeed and occasionally and inexplicably fail.
Ian
--
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.
