2009/12/16 kedar mhaswade <kedar.mhaswade_at_gmail.com>
>
>
> On Tue, Dec 15, 2009 at 9:02 PM, gustav trede <gustav.trede_at_gmail.com>wrote:
>
>>
>>
>> 2009/12/15 kedar mhaswade <kedar.mhaswade_at_gmail.com>
>>
>>
>>>
>>> On Tue, Dec 15, 2009 at 7:16 AM, gustav trede <gustav.trede_at_gmail.com>wrote:
>>>
>>>>
>>>>
>>>> 2009/12/15 Justin Lee <Justin.Lee_at_sun.com>
>>>>
>>>> Right. LinkedTransferQueue, e.g., is a JDK7 class so it's not even in
>>>>> Java6 (yet?).
>>>>>
>>>>> LTQ shines for clean fixed Thread pool implementations when no extra
>>>> fluff is needed.
>>>> If anybody finds a more scalable way to implement a threadpool then the
>>>> current poison based Fixed pool in grizzly it would be good to know, so we
>>>> can ensure we got the best thing possible.
>>>> LBQ does perform better for a few threads that consume/produces
>>>> extremely short tasks, but it dont scale well.
>>>>
>>>
>>> Hello Gustav,
>>>
>>> JCiP (the book Java Concurrency in Practice) contains a comparison of LBQ
>>> and ABQ (ArrayBlockingQueue) and demonstrates that LBQ "scales" better on
>>> multi-core machine (that they chose). Is a similar comparison available
>>> somewhere with regards to LTQ and LBQ?
>>>
>>>
>> What is written in an old book about two datastructures A and B has
>> nothing to do with A and C..
>> That information is only of historical and general education interest.
>> I have read that book several times,im slow at learning =). it does have
>> some valuable timeless knowledge about memory models and safe publishing
>> etc.
>>
>> I have stated multiple times on this mailing list that its only during the
>> latest few months that the LTQ implementation has become good.
>>
>> Synchronized and atomics/volatile loops are both concept that dont scale
>> well when failure rate is high,
>> due to cpu caches are severly trashed etc.
>>
>
> Can you explain what you mean by "failure rate"?
>
When load is high enough, synchronized or lock gets contended, atomics
incrementandget etc tends to deteriorate to approach synchronized level of
scalability.
Best is to read about these matters in general, follow openjdk hotspot,
concurrency maling list
http://cs.oswego.edu/mailman/listinfo/concurrency-interest.
There is quite often interesting discussions where the full complexity
sometimes is probed and finally completely explained/analyzed if we are
lucky.
The detailed documentation available for the current LTQ,CLQ is a very good
source for its specifics :
In jdk7 or doug cvs
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/
.<
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedTransferQueue.java?revision=1.20&view=markup>
>
>> Looking at the code you can see that LTQ is designed to avoid sharing
>> (and hence trashing) cachelines.
>>
>> Real world like or specific carefully designed technical tests on _modern_
>> hardware and JVMs, verify the findings, try to understand from a theoretical
>> point of view is IMO what counts.
>> I did my best efforts to do so regarding LBQ vs LTQ with one of that book
>> authors Doug lea that also is the author of LTQ.
>>
>
> Ah ok. Need to understand this better. Maybe one of these days ...
>
Well, my best efforts is only that. feedback from others and whats best
solution when all abstract aspects is considered in a community concensus is
the real answer.
Its a rapidly evolving combination of hardware, JVM and datastructures etc.
It requires a personal interest inorder to even be somewhat up to date of
the current situation.
>>
>>> Also, will it be better if we created a Java 1.5 maven artifact of these
>>> classes rather than checking them into SCM?
>>>
>>> Your imo free to commit any change you want.
>> What is the exact problem that it would fix, does OSGI have problems or
>> what is it ?.
>>
> Don't know about OSGi, but it will probably solve the problem of not
> checking in something (e.g. class files) that are generally not a version
> controlled entities. But anyway, I am not hard pressed for it if none else
> sees that as a problem.
>
Im not skilled at maven xml stuff, if its somehow needed to use maven
artifacts or other tricks i gladly get helped with it.
--
regards
gustav trede