TempAlloc

Fawzi Mohamed fmohamed at mac.com
Sun Dec 7 10:20:24 PST 2008


On 2008-12-07 18:44:30 +0100, dsimcha <dsimcha at yahoo.com> said:

> == Quote from Fawzi Mohamed (fmohamed at mac.com)'s article
>> it could simply be an int storing the place in the stack...
>> So if someone forgets to remove the frame the next call will see it
>> immediately.
>> By the way couldn't you avoid the thread local State by simply keeping
>> a stack of State structures?
>> Then instead of the thread local State you would simply look at the top
>> of the State Stack, it should be faster and more self contained.
> 
> I really don't see how this can work.  AFAIK, there are only 4 ways to 
> deal with
> global mutable state in a multithreaded program:
> 
> 1.  Locking.
> 2.  Somehow do everything atomically, if you can.
> 3.  Make the "global" state thread-local.
> 4.  Eliminate it altogether.
> 
> The biggest reason for me writing TempAlloc in the first place was to 
> avoid lock
> contention for GC malloc access.  TempAlloc is somewhat faster even in
> single-threaded tests, but the really huge, orders of magnitude 
> speedups come when
> it's used to avoid this contention.

mmh sorry this comes from not having really understood how TmpAlloc was 
supposed to work.
Indeed if you want to hide completely the presence of a State, and not 
pass it explicitly to the allocation routines you cannot avoid thread 
local.

I was mislead by the name, State is actually the superstack object, 
what I meant was to keep an extra index in it that simply counts the 
number of frames, and return/ask it in initFrame freeFrame so that you 
can check that you did not have any mismatched frames.



More information about the Digitalmars-d-announce mailing list