concurrency

Sean Kelly sean at f4.ca
Tue Feb 5 07:14:19 PST 2008


There's also a presentation about how it might apply to D here:

http://s3.amazonaws.com/dconf2007/DSTM.ppt
http://www.relisoft.com/D/STM_pptx_files/v3_document.htm

Bedros Hanounik wrote:
> Guys,
> 
> take a look at transactional memory concept;  very interesting type of locking (or should I say sharing) of memory allocations.
> 
> http://en.wikipedia.org/wiki/Software_transactional_memory
> 
> 
> 
> -Bedros
> 
> 
> Sean Kelly Wrote:
> 
>> Daniel Lewis wrote:
>>> Sean Kelly Wrote:
>>>> This is basically how futures work.  It's a pretty useful approach.
>>> Agreed.  Steve Dekorte has been working with them for a long time and integrated them into his iolanguage.  He found he could regularly get comparable performance to Apache even in a pure OO framework (even Number!?) just 'cause his parallelization was better.
>>>
>>> I personally believe the best way though is to take advantage of lock instructions for *allocation* of memory.  Once memory is allocated, it's "yours" to do with as you please.  I haven't looked at this for a few months but I remember seeing an algorithm that did first-through concurrency loop-locks for malloc and free and had practically no overhead ever.
>> Actually, it's entirely possible to do lock-free allocation and
>> deletion.  HOARD does lock-free allocation, for example, and lock-free
>> deletion would be a matter of appending the block to a lock-free slist
>> on the appropriate heap.  A GC could do basically the same thing, but
>> collections would be a bit more complex.  I've considered writing such a
>> GC, but it's an involved project and I simply don't have the time.
>>
>>
>> Sean
> 



More information about the Digitalmars-d mailing list