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