Commit ba243592 authored by Nathan Bronson's avatar Nathan Bronson Committed by woo

cautionary comment in futexWake

Summary:
Add a description of the fault-after-unlock problem that can
occur when a synchronization object is used to guard its own
destruction.

Test Plan: comment change only

Reviewed By: alikhtarov@fb.com

Subscribers: trunkagent, folly-diffs@

FB internal diff: D1808446

Signature: t1:1808446:1422481173:83c0369e2277cd5b8cf6377fcd92b132019611a7
parent ec9fc0c6
...@@ -102,8 +102,14 @@ struct Futex : Atom<uint32_t>, boost::noncopyable { ...@@ -102,8 +102,14 @@ struct Futex : Atom<uint32_t>, boost::noncopyable {
} }
} }
/** Wakens up to count waiters where (waitMask & wakeMask) != 0, /** Wakens up to count waiters where (waitMask & wakeMask) !=
* returning the number of awoken threads. */ * 0, returning the number of awoken threads, or -1 if an error
* occurred. Note that when constructing a concurrency primitive
* that can guard its own destruction, it is likely that you will
* want to ignore EINVAL here (as well as making sure that you
* never touch the object after performing the memory store that
* is the linearization point for unlock or control handoff).
* See https://sourceware.org/bugzilla/show_bug.cgi?id=13690 */
int futexWake(int count = std::numeric_limits<int>::max(), int futexWake(int count = std::numeric_limits<int>::max(),
uint32_t wakeMask = -1); uint32_t wakeMask = -1);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment