TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Reference Counting: Harder Than It Sounds

53 点作者 sanjoy_das将近 9 年前

4 条评论

akkartik将近 9 年前
This is probably simplistic, but in my safe, toy assembly language for teaching programming I simply avoid ever sharing (always refcounted) pointers between threads. Instead it pervasively uses channels for communication, and while channels are generic anything you put in them gets deep-copied on write. The deep copy is smart enough to preserve cycles, so say if you send in a linked list that contains a cycle the reader will see a linked list with an identical topology. It will just be <i>utterly</i> disjoint with the original linked list.<p>These design decisions allow me to provide safe pointer access and avoid all race conditions while teaching programming and concurrency, but they probably incur significant performance loss on certain programs. My hope is that the design constraints they impose on the programmer aren&#x27;t insurmountable. We&#x27;ll see.<p>(More info on the project: <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu#readme" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu#readme</a>. On its memory model: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11855470" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11855470</a>. On the deep-copy implementation: <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu&#x2F;blob&#x2F;07ab3e3f35&#x2F;073deep_copy.cc#L243" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu&#x2F;blob&#x2F;07ab3e3f35&#x2F;073deep_copy....</a>)
评论 #12153688 未加载
评论 #12152989 未加载
评论 #12153136 未加载
评论 #12154119 未加载
zzzcpan将近 9 年前
I&#x27;m thinking, for shared refcounted pointers would it be better to just move synchronization off the critical path completely? I mean operate on local pointers in each thread, like it&#x27;s a single threaded app, but every hundred decrements merge their counters. And release memory only if counters were zero and synchronized for some time, i.e. for at least a couple of synchronizations on every thread or something. It should be possible to get an order of magnitude better performance, than with any kind of synchronized refcounters.
评论 #12153807 未加载
评论 #12153636 未加载
nwalfield将近 9 年前
One way to reduce the cost of cross CPU synchronization is to use sloppy reference counters:<p>&quot;An Analysis of Linux Scalability to Many Cores&quot; (<a href="https:&#x2F;&#x2F;pdos.csail.mit.edu&#x2F;papers&#x2F;linux:osdi10.pdf" rel="nofollow">https:&#x2F;&#x2F;pdos.csail.mit.edu&#x2F;papers&#x2F;linux:osdi10.pdf</a>)
radiospiel将近 9 年前
I don&#x27;t see how in the example thread b&#x27;s refcount could be zero, since there would exist a reference on thread a already (or else A could not create another reference) So how can that happen?
评论 #12153665 未加载