concurrency

[Sean Kelly]

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