[concurrency-interest] Propagation ofsignalstonon-interruptedthread

David M. Lloyd david.lloyd at redhat.com
Tue Nov 15 14:37:59 EST 2011


Seems necessary to me though - somewhere you have to record what threads 
are waiting for the lock so you can wake one of them up when it becomes 
available.

On 11/15/2011 01:27 PM, √iktor Ҡlang wrote:
>
>
> On Tue, Nov 15, 2011 at 7:59 PM, Dr Heinz M. Kabutz
> <heinz at javaspecialists.eu <mailto: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  <tel:%2B30%2069%2072%20850%20460>
>     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 <mailto: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
>>     <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/>- 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


-- 
- DML


More information about the Concurrency-interest mailing list