qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Interesting piece of work for C++
Date Wed, 04 Feb 2009 02:44:56 GMT
Rajith Attapattu wrote:
> On Mon, Feb 2, 2009 at 6:05 PM, Carl Trieloff <cctrieloff@redhat.com> wrote:
>
>   
>> Some of the work being done has been around performance. At this point we
>> have 2 locks
>> that still need some work.
>>
>> One of these locks are in the OS memory allocator, to this end I have
>> spoken to the glic/gcc
>> maintainers and they are working on a better malloc/free for us. However
>> the other side of the
>> equation is to do some optional memory caching.
>>
>> The biggest area where this will help us is around frame caching. An
>> experiment in this area
>> has been done with TLS caching (did not work out as the caches need to be
>> cross thread) and
>> a global pool test has determined that we can reduce the number of
>> allocations by 25% with
>> such a cache.
>>
>> However to do this we need a lock free bucket. So, if someone has interest
>> to create a lock free bucket.
>>
>> I.e. a lock free structure that you can push pointers into and pop them
>> back off from many threads at
>> the same time. If the bucket is empty return NULL. No ordering is required.
>>
>> What is interesting in that all the cost in a lock free fifo is the
>> corrections to maintain order which we
>> don't need. so the CAS or DCAS impls of fifo without order can be used. For
>> algorithms see work
>> from Maged M. Michael & Michael L. Scott  -- or google a bit
>>
>>     
>
> I had a stab at this sometime back. Started to experiment with the lock free
> version first.
> I think you would need DCAS as you need to swap both the pointer and the
> counter atomically.
> Not sure if this can be achieve with CAS only, especially when u move to 64
> bit machines.
> Also not all processors support DCAS either. So I gave up this route.
>
> I think a more feasible approach might be the two-lock queue . I had some
> code around this.
> Unfortunately haven't had much time to tinker with it any further. I believe
> Andrew/Gordon had done a simillar execersie.
> Andrew had some thoughts around this, perhaps he could chime in.

we don't need fifo for this case, so it can be done with atomics, cas or 
dcas - no locks needed.
Carl.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message