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

很多公司都是常年挂着招聘，有些还约人去面试，招不招人只有他们老板心里知道

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

是国企或者事业单位吗？

@teli 同问
可以电话或者视频面试吗？本科学历是硬性门槛吗？

@lysS “不应该用 atomic.Value 存指针”的原因？
我看官方文档并无此要求。

@lysS 还请直言，具体的错误是什么

@pheyer 搞定
chrome settings 里有个语言列表，chinese 不能在最上面

@pheyer
我把 google 账户的语言改了，切换到了英文版 chrome 商店
然后再 install Evernote Web Clipper ，依然是国内版……

@lysS 没理解你的意思
你的意思是，Range 应该在调用时，给整个结构体的数据，取一次快照，然后 Range 遍历的是快照的内容？？
目前 freesync.Slice 的 Range ，是每次调用 f 时，Load 值。
我试着把你那段代码里的 Slice ，换成 sync.Map ，两边输出结果是一样的。

@lesismal
纠正下错别字

如果是 bag 和 sync.Mutex+内置 map 的 benchmark 的比较，
根据我这边的的 benchmark 测试结构
只 add 的话，bag 会有几倍的优势
add+delete ，两者结果差不多
benchmark 代码见最新的提交

@lesismal
如果是 bag 和 sync.Mutex+内置 map 的 benchmark 的比较，
根据我这边的的 benchmark 测试结构
只 add 的话，bag 会有几倍的优势
add+delete ，两者结构差不多
benchmark 代码见最新的提交

freesync/lockfree 也实现了一个单链表，bag 也用到了这个单链表，但是还要继续优化。

你的 nbio ，我好好学习下，再请教。
额外问下，nbio 是不是牛逼 io 的意思？

@yulgang 谢谢。现在问题是一些程序，需要在 /系统目录下放一些大数据文件。
/挂载的分区是 30 多 GB 。
电脑挂载了两块硬盘。我也尝试用软目录的方式，来引导程序把一些数据文件放到另外一块硬盘上去，但失败了。

@lesismal
还有 freesync.Bag 和 sync.Map 比 Write 的问题，
开发 freesync.Bag 的出发点，就是 sync.Map 对读多友好，写多稍逊。Bag 为并发写多的场景设计。

@lesismal
多谢

我为 Bag 和 Slice 增加了新的 benchmark 测试用例：
bag 增加了和 sync.Map 、sync.Mutex+map 比纯 Add/Store ，和比 Add/Store + Delete 。
slice 增加了 LoadAndUpdate 。

下面这个，烦劳提供改动后的代码：
BenchmarkBagWrite-16 3418212 347.2 ns/op 87 B/op 3 allocs/op
BenchmarkSyncMapWrite-16 5754406 219.8 ns/op 0 B/op 0 allocs/op

slice 的 Load 问题，如果是纯 Load ，Load 时没有 Append 和 Update ，确实不需要加锁。
但如我上面所说：任何解决方案，都只可能适用于特定场景。freesync.Slice 考虑的是并发安全读写。原生 slice 不加锁进行纯 Load ，和 freesync.Slice 纯 Load ，两者没有可比性，如果真要比，我反倒觉得对 freesync.Slice 不公平。好比让飞机和汽车比在地上跑道比谁跑得快。

至于无锁数据结构，能发挥的场景较少。这个我承认。
写这些，主要原因是最近几个月没工作，家里闲着。
欢迎提供能发挥场景多的无锁数据结构需求。

最后，我这边 benchmark 测试的条件为：
goos: linux
goarch: amd64
cpu: AMD Ryzen 7 1800X Eight-Core Processor

@rekulas
1. freesync 为并发场景设计。
性能列描述的是本机 benchmark 测试的结果，benchmark 代码见 XXX_benchmark_test.go 文件。希望诸位朋友能够提供在各自的机器上执行的 benchmark 的输出。
2. 任何解决方案，都只可能适用于特定场景。
““决定”访问一个 freesync.slice 的时候”，这个需要在“决定”时对整个 slice 做一次快照，或者在“决定”时阻塞其它写操作；
“写一个 slice 的时候，可能也有其他协程在更新它，可能不是用户期望的”，如果是并发 Append ，互不影响；如果是 UpdateAt 不同的索引，互不影响；如果是 UpdateAt 同一索引，后面的更新会覆盖前面的更新——除非 CompareAndSwap 。但目前的实现不支持在指定位置 CompareAndSwap 。
3. 我喜欢“较新”的产品，不喜欢“太新”的产品。后面应该会支持泛型。

什么项目？

特殊时期，少换工作

@lysS
slice 只是个名字而已，没必要纠结“slice” delete 操作是否合理。
最终实现，应该不会叫 slice 。到时具体看底层数据结构，或者另外取个跟底层数据结构无关的名字。
根据基准测试结果，基于 mutex 和基于原子的 free-lock 操作，两者性能差距还是很明显。