Mailing-List: contact kafka-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kafka-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of e.vanoosten@grons.nl
 designates 83.163.41.27 as permitted sender)
Message-ID: <4EB03BC0.6060704@grons.nl>
Date: Tue, 01 Nov 2011 19:34:40 +0100
From: Erik van Oosten <e.vanoosten@grons.nl>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: kafka-dev@incubator.apache.org
Subject: Re: KAFKA-50 replication support and the Disruptor
References: <4EADAD36.6080406@grons.nl>
 <CAOeJiJhYNgU2MwqeHBkKGF-RAZE3nESZYHLZKOoRgcnARixYDw@mail.gmail.com>
 <CFAB5F27-AC2F-4653-BBB2-FA4C86CCF676@grons.nl> <4EAF0747.3090804@gmail.com>
In-Reply-To: <4EAF0747.3090804@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

There are several wait strategies. You will want to use spin lock in 
production environments where you should have enough CPU cores anyway. 
Remember, the 'real' work runs in another always running thread that 
also uses a spin lock to wait for more work.
In dev environment or hosts that need to do lots of other stuff, you 
definitely need another wait strategy.

     Erik.


Op 31-10-11 21:38, Chris Burroughs wrote:
> On 10/31/2011 04:23 AM, Erik van Oosten wrote:
>> That is not the point (mostly). While you're waiting for a lock, you can't issue another IO request. Avoiding locking is worthwhile even if CPU is the bottleneck. The advantage is that you'll get lower latency and also important, less jitter.
> /begin{Tangent}
>
> Doesn't the Disruptor use a spin lock though?  I would expect that to
> not play nice if sharing a core with CPU bound threads doing 'real' work.


-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/