TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Show HN: Evenk C++ concurrency library

35 pointsby avdiciusabout 10 years ago

6 comments

davidtgoldblattabout 10 years ago
Nice work! I have some suggestions for future improvements:<p>- Your CPUCycle class doesn&#x27;t actually do backoff. atomic_thread_fence(m_o_relaxed) is a no-op, and at least one compiler (recent clang versions) will optimize the loop away entirely. You can fix by reading from a volatile variable inside the loop.<p>- Similarly, nanosleep on linux will busy-loop instead of returning to the scheduler for small delays; this seems not to be the goal for some of the backoff schemes<p>- The BoundedQueue assumes that a futex call functions as a &quot;full memory fence&quot;. I&#x27;m not terribly familiar with the linux kernel internals, but I don&#x27;t believe this to be the case. On Power, for instance, it appears to not always generate a sync instruction, instead using lwsync or isync. I haven&#x27;t looked at the queue closely enough to tell if this poses a correctness issue, but it definitely looks weaker than atomic_thread_fence(m_o_seq_cst).<p>- The SpinLock uses a test-and-set loop; test-and-test-and-set will often scale much better because of the reduced cache coherency traffic required.<p>- Similarly, using NoBackoff as the default backoff strategy seems to impose a likely performance penalty on users who aren&#x27;t familiar with the need for backoff.<p>- The FutexLock code looks a little screwy to me. Why backoff if you&#x27;re likely going to do a futex operation anyway? Why is the Lock()&#x27;s unconditional discarding of the exchanged value safe? It seems like you have the potential for missed wakeups. But it&#x27;s late and I&#x27;m tired, so I&#x27;m probably just missing something.<p>I don&#x27;t mean to be critical, it&#x27;s just that code reviews only ever contain nits. I&#x27;m excited that somebody is working on locking primitives that are more efficient than glibc pthreads (whose performance I&#x27;m not a huge fan of).
评论 #9434000 未加载
frozenportabout 10 years ago
Would strongly encourage the author to put an example on the front page of the repo. I have no clue what this is, is it like ZMQ, std::thread?
评论 #9431510 未加载
ngbronsonabout 10 years ago
One option for compatibility on non-futex platforms is to write your own futex emulation using striped std::mutex or pthread_mutex_t. The emulated futex API still has the same slow-path-only goodness as a real futex, but is fully portable.<p>For an example of this technique, check out <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;folly&#x2F;blob&#x2F;master&#x2F;folly&#x2F;detail&#x2F;Futex.cpp#L133" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;folly&#x2F;blob&#x2F;master&#x2F;folly&#x2F;detail&#x2F;F...</a> . That code only implements wake and wait, but it would be straightforward to extend it to the other futex operations.
mcrossabout 10 years ago
What license are you distributing the code under? I don&#x27;t see any license noted in your repo.
评论 #9455230 未加载
halayliabout 10 years ago
for those interested in C++ based concurrency lib, check out lthread_cpp. It&#x27;s a wrapper around lthread.<p><a href="http:&#x2F;&#x2F;lthread-cpp.readthedocs.org" rel="nofollow">http:&#x2F;&#x2F;lthread-cpp.readthedocs.org</a>
Svenstaroabout 10 years ago
Any docs at all?
评论 #9431146 未加载