https://github.com/davecheney/junk/tree/master/id <https://github.com/davecheney/junk/tree/master/id> but see the warnings.
Still, I would use mutex and shared caches until you can prove that the costs matter before resorting to the library. You might be interested in github.com/robaho/go-concurrency-test > On Jul 23, 2019, at 9:55 PM, Zihan Yang <whois.zihan.y...@gmail.com> wrote: > > CGO sounds good, but I remember CGO invocation is not cheap? (not sure where > I saw it). > > Would you provide a reference to "Chaney id project"? I don't find much > information about it. > > I will look into the named goroutine discussion. > > Thanks. > > 在 2019年7月24日星期三 UTC+8上午1:52:35，Robert Engels写道： > You will need to use CGo. See Chaney “id” project for ideas. Since the > underlying OS threads are shared and will not be switched while in the C code > it is fairly straightforward but having a robust typed cache will be > problematic. > > There are discussions on golang-dev about named Go routines which might be a > workaround, but so far the TLS (or PLS) discussion has been a non starter. > > On Jul 23, 2019, at 12:10 PM, Zihan Yang <whois.z...@gmail.com <>> wrote: > >> I am trying to implement an LRU cache. Several global lru lists could be >> accessed concurrently by multiple goroutines, which could be a disaster in a >> machine with 24 or more cores. >> >> >> >> Therefore, it would be great if I can add the item to P-local storage and >> flush the batched item into the lru list as a whole. This should greatly >> reduce the contention for the global lru list. >> >> >> >> How can I do it? I saw some related github issues, #8281 >> <https://github.com/golang/go/issues/8281> and #21355 >> <https://github.com/golang/go/issues/21355>, which leads me to a project >> called gls <https://github.com/jtolds/gls>, but the code seems too much to >> integrate into my project (actually I'd better not include any third-party >> package to avoid potential law issues). Is there any built-in way to achieve >> this? >> >> >> >> Thanks >> >> >> -- >> 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 golan...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/c79d3801-2f03-43fd-8dd8-35904b481341%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/c79d3801-2f03-43fd-8dd8-35904b481341%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/bd54928f-cac5-4886-9252-04812f72b299%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/bd54928f-cac5-4886-9252-04812f72b299%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/B815A880-D5D2-4DA5-BE7A-041335EE48EE%40ix.netcom.com.
