I reviewed the code and it is still pretty inefficient compared to a local free
list. I don’t think the single local element helps in the binary tree case
anyway, as you are probably releasing branches of the tree at a time. Also, in
the face of high cpu based concurrency/contention, the local
> Unclear… revise… “it requires a lock & unlock for every get and put of an
> item"
Not quite exactly. One item per scheduler (could be count as native thread) is
stored in fast thread local storage. Yes, there are still locks, but for
separate lock per thread, and this is quite cheap, since no
Is there a more concise way to write
var check = 1 + self.left.itemCheck() + self.right.itemCheck()
pool.Put(self.left)
self.left = nil
pool.Put(self.right)
self.right = nil
return check
--
You received this message because you are subscribed to the Goog
Unclear… revise… “it requires a lock & unlock for every get and put of an item"
> On Mar 6, 2019, at 5:31 PM, robert engels wrote:
>
> Any use of sync.Pool is kind of a misuse in my opinion. If you review the
> code, it requires unlock/lock to get/put an item - not very cheap, and not
> great
Any use of sync.Pool is kind of a misuse in my opinion. If you review the code,
it requires unlock/lock to get/put an item - not very cheap, and not great for
highly concurrent situations - best to only use it for objects that are shared
that are very expensive to instantiate, or unshared pools
Is this a misuse of sync.Pool?
How would a Go programmer re-write the ugly `t.left =` `self.left =` ?
package main
import (
"fmt"
"sync"
)
type Node struct {
left, right *Node
}
var pool = sync.Pool {
New: func() interface{} {
re
