[concurrency-interest] Propagation ofsignalstonon-interruptedthread

Nathan Reynolds nathan.reynolds at oracle.com
Fri Nov 18 12:09:48 EST 2011


If GC is a concern, the implementation could be changed so that a static 
ThreadLocal caches the AbstractQueuedSynchronizer$Node for each thread.  
The question is if the AbstractQueuedSynchronizer$Node can be reused 
without running into other concurrency issues such as ABA.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 11/15/2011 12:46 PM, Dimitris Andreou wrote:
> Which is (almost) the same deal as with synchronized blocks. The
> difference is that the allocated object is from a native object pool,
> not in the java heap, so no extra gc overhead involved there.
>
> 2011/11/15 Dr Heinz M. Kabutz<heinz at javaspecialists.eu>:
>> Just a follow-up on my last post.  This object is only constructed when
>> there is contention over the lock.
>>
>> Regards
>>
>> Heinz
>> --
>> Dr Heinz M. Kabutz (PhD CompSci)
>> Author of "The Java(tm) Specialists' Newsletter"
>> Sun Java Champion
>> IEEE Certified Software Development Professional
>> http://www.javaspecialists.eu
>> Tel: +30 69 72 850 460
>> Skype: kabutz
>>
>>
>> On 11/15/11 9:27 PM, √iktor Ҡlang wrote:
>>
>> On Tue, Nov 15, 2011 at 7:59 PM, Dr Heinz M. Kabutz
>> <heinz at javaspecialists.eu>  wrote:
>>> On an only vaguely related note, I discovered today, whilst doing a
>>> throughput test of atomic integer vs reentrant lock, that every time you
>>> call lock.lock(), it creates a new object of 32 bytes!  For some reason, I
>>> always assumed that lock.lock() would not construct any objects, so was
>>> surprised when the GC started acting up.  The object that is constructed is
>>> the AbstractQueuedSynchronizer$Node in the addWaiter() method in the
>>> AbstractQueuedSynchronizer.
>> Yeah, that one's a real treat.
>>
>>> Regards
>>>
>>> Heinz
>>> --
>>> Dr Heinz M. Kabutz (PhD CompSci)
>>> Author of "The Java(tm) Specialists' Newsletter"
>>> Sun Java Champion
>>> IEEE Certified Software Development Professional
>>> http://www.javaspecialists.eu
>>> Tel: +30 69 72 850 460
>>> Skype: kabutz
>>>
>>>
>>> On 11/15/11 4:57 PM, Martin Buchholz wrote:
>>>
>>> On Mon, Nov 14, 2011 at 18:37, David Holmes<davidcholmes at aapt.net.au>
>>> wrote:
>>>> One example of some broken code is not very compelling. This code doesn't
>>>> even handle timeout correctly. I strongly suspect the author of this code
>>>> was not relying on no-spurious-wakeups but was simply completely ignorant of
>>>> them and so would have used the same style of code even with Object.wait.
>>> Sure.
>>> My argument is not about careful programmers who have thoughtfully read
>>> the spec, whose number is vanishingly small.  This is all about real-world
>>> crappy code in production that happens to work today, and will fail
>>> unpredictably under stress if you withdraw the de-facto guarantees.
>>> If Object.wait has also been providing the de-facto guarantee in recent
>>> releases, I would like its spec updated as well to provide the stronger
>>> guarantee.  But my argument is stronger for j.u.c.locks, since everyone uses
>>> the same implementation in practice.
>>> Martin
>>>
>>> ________________________________
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>>
>> --
>> Viktor Klang
>>
>> Akka Tech Lead
>> Typesafe - Enterprise-Grade Scala from the Experts
>>
>> Twitter: @viktorklang
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111118/ffada286/attachment.html>


More information about the Concurrency-interest mailing list