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