RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all
Dmitry Samersoff
dmitry.samersoff at oracle.com
Thu Mar 3 09:50:13 UTC 2016
Thomas,
> The more I look at this, the more I think that the costs for a
> pthread mutex lock are acceptable in this case: we are about to do a
> blocking IO operation anyway, which is already flanked by two mutex
> locking calls (in startOp and endOp). I doubt that a third mutex call
> will be the one making the costs suddenly unacceptable. Especially
> since they can be avoided altogether for low value mutex numbers (the
> optimization Roger suggested).
After closer look to the code in a whole - I agree with you.
-Dmitry
On 2016-03-03 12:32, Thomas Stüfe wrote:
> Hi Hans,
>
> On Thu, Mar 3, 2016 at 4:08 AM, Hans Boehm <hboehm at google.com
> <mailto:hboehm at google.com>> wrote:
>
>
> On Wed, Mar 2, 2016 at 12:09 AM, Thomas Stüfe
> <thomas.stuefe at gmail.com <mailto: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.
>
>
>
> Thank you for that excellent explanation!
>
> This may be just my ignorance, but I actually did not know that
> atomics are now a part of the C standard. I took this occasion to
> look up all other C11 features and this is quite neat :) Nice to see
> that C continues to live.
>
> I am very hesitant though about introducing C11 features into the
> JDK. We deal with notoriously oldish compilers, especially on AIX,
> and I do not want to be the first to force C11, especially not on
> such a side issue.
>
> The more I look at this, the more I think that the costs for a
> pthread mutex lock are acceptable in this case: we are about to do a
> blocking IO operation anyway, which is already flanked by two mutex
> locking calls (in startOp and endOp). I doubt that a third mutex call
> will be the one making the costs suddenly unacceptable. Especially
> since they can be avoided altogether for low value mutex numbers (the
> optimization Roger suggested).
>
> I will do some performance tests and check whether the added locking
> calls are even measurable.
>
> Thomas
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
More information about the core-libs-dev
mailing list