concurrency

[Bedros Hanounik]

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