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