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.
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.
> 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 ?.
--
regards
gustav trede