TempAlloc

dsimcha dsimcha at yahoo.com
Sun Dec 7 09:44:30 PST 2008


== 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.

> Then the element to check could really be the size of the stack, and if
> it is simply an int you can make it optional, if present you check for
> mismatches... and you get rid of passing the State out...
> int initFrame()// returns the number of frames of the stack
> void freeFrame(int handler=-1)// frees the frame, if handler is >=0
> then checks the number of frames

I thought about doing something like this. The biggest problem is large blocks.
Since frequent very large allocations are where GC performance really suffers and
false pointer issues turn up, I wanted to make sure that these get deleted
deterministically, too.

Also, just to note:  I realized that I had not taken into account alignment when I
first wrote TempAlloc.  I've updated it to use 16-byte alignment (good for x86),
and to fix tempdup to work right with const.




More information about the Digitalmars-d-announce mailing list