On 2008-12-07 18:44:30 +0100, dsimcha <[EMAIL PROTECTED]> said:
== Quote from Fawzi Mohamed ([EMAIL PROTECTED])'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.
