实现了一套基于 lockfree 的并发安全的数据结构

[wencan]

https://github.com/wencan/freesync

https://pkg.go.dev/github.com/wencan/freesync

本项目包含两个部分，freesyn/lockfree 为一套无锁的基础数据结构。freesync 为一套基于无锁基础数据结构的简单复合结构。freesyn/lockfree 完全是 lockfree ，freesync 利用了 sync.Mutex 。

包	结构	说明	性能
freesync/lockfree	LimitedSlice	无锁的长度受限的 Slice
freesync/lockfree	SinglyLinkedList	无锁的单链表
freesync/lockfree	Slice	无锁的支持增长的 Slice
freesync	Slice	并发安全的 Slice	与官方 slice+mutex 相比，写性能提升一半，读性能提升百倍左右
freesync	Bag	并发安全的容器	与 sync.Map 相比，写性能提升一半左右

麻烦各路大佬指点。如果能发现 bug 更好。

[lysS]

@tsotsi range 的时候读取是更新前的还是后的，这取决于设计（是整体的并发安全还是对元素的并发安全）。从这个角度来说我那个 ut 不太准确。

但还是那个结论。如果把竞争检测开启，我那个 ut 会有竞争、而你那个 sync.Map 不会有

[tsotsi]

@lysS 你的代码去掉也不行。哈
建议用我的
https://go.dev/play/p/qyHVGs36Hkn
@wencan

[lysS]

@tsotsi 去掉也不行什么意思？ 我那个是 ut 是证明 op 的那个库是并发不安全的

[wencan]

@lysS @tsotsi
我重新跑了 freesync.Slice 和 freesync.Bag 的全部 unit test 和 branchmark test ，全部输出符合预期，没检测到 data race 。

[tsotsi]

@wencan 我的。🤡了

[lysS]

@wencan 数据竞争是有的，只不过不容易测出来吧。
比如函数 func (slice *Slice) Append(p interface{}) int 中，在互斥锁之前会读 limitSlicesNum ，互斥锁之后会写 limitSlicesNum 。而且这两个是可以同时发生的。

[lysS]

话说你都加了互斥锁了，那个 slice 的 value 完全没必要用 atomic.Value 了

[lysS]

还有，我看你里面有自旋，这显然是不太好的

[lysS]

@wencan L19 最好不存指针大概是这种情况：

func Benchmark_Race(b *testing.B) {

var i int
var at atomic.Value = atomic.Value{}
at.Store(&i)

b.RunParallel(func(p *testing.PB) {
for p.Next() {
*(at.Load().(*int))++
}
})
}

[wencan]

lockfree.Slice 创建之后，limitSlicesNum 是只读
查了下，slice 的用 value 的地方，都存在并发读写的可能。不知道你说的具体是哪里的 value ？
at.Store(&i)里 &i 不就是地址吗？
@lysS

[lysS]

@wencan limitSlicesNum 在 grow 会被写啊，就是

https://github.com/wencan/freesync/blob/9000626a5e8936710ce6b512051a940c46733f99/slice.go#L24

https://github.com/wencan/freesync/blob/9000626a5e8936710ce6b512051a940c46733f99/slice.go#L50

并发时，会有竞争