[concurrency-interest] Propagation ofsignalstonon-interruptedthread

Dimitris Andreou jim.andreou at gmail.com
Tue Nov 15 14:46:34 EST 2011


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
>
>



More information about the Concurrency-interest mailing list