RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

[Hans Boehm]

On Wed, Mar 2, 2016 at 12:09 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:
>
> Hi Hans,
>
> thanks for the hint!
>
> But how would I do this for my problem:
>
> Allocate memory, zero it out and then store the pointer into a variable
seen by other threads, while preventing the other threads from seeing . I
do not understand how atomics would help: I can make the pointer itself an
atomic, but that only guarantees memory ordering in regard to this
variable, not to the allocated memory.
>
> Kind Regards, Thomas

C11 atomics work essentially like Java volatiles: They order other memory
accesses as well.  If you declare the pointer to be atomic, and store into
it, then another thread reading the newly assigned value will also see the
stores preceding the pointer store.  Since the pointer is the only value
that can be accessed concurrently by multiple threads (with not all
accesses reads), it's the only object that needs to be atomic.  In this
case, it's sufficient to store into the pointer with

atomic_store_explicit(&ptr, <new_value>, memory_order_release);

and read it with

atomic_load_explicit(&ptr, memory_order_acquire);

which are a bit cheaper.

However, this is C11 specific, and I don't know whether that's acceptable
to use in this context.

If you can't assume C11, the least incorrect workaround is generally to
make the pointer volatile, precede the store with a fence, and follow the
load with a fence.  On x86, both fences just need to prevent compiler
reordering.