• dsimcha (10/10) Oct 24 2009 Does anyone know if alloca() is by some chance not thread safe? I'm wor...
• Denis Koroskin (6/25) Oct 24 2009 You are probably misusing alloca (e.g. returning it from a function) or ...
• dsimcha (4/30) Oct 24 2009 Yep, you're right. There was a very subtle and interesting bug in my co...

dsimcha <dsimcha yahoo.com> writes:

Does anyone know if alloca() is by some chance not thread safe?  I'm working
on improving my parallelization library and I keep running into all kinds of
erratic behavior (but not stack overflows) when I use alloca() instead of heap
as an optimization, but when I disable this optimization, everything seems to
work.  I do know that several threads are likely calling alloca() at the same
time and with requests large enough that their stacks might need to be expanded.

At first, I thought this was just a symptom of a subtle race condition, but I
tried inserting sleep statements and synchronized blocks in various places
around the alloca() calls to change the timing of things and the conclusion is
the same:  malloc() works, alloca() doesn't.

"Denis Koroskin" <2korden gmail.com> writes:

On Sun, 25 Oct 2009 03:34:24 +0300, dsimcha <dsimcha yahoo.com> wrote:

 Does anyone know if alloca() is by some chance not thread safe?  I'm  
 working
 on improving my parallelization library and I keep running into all  
 kinds of
 erratic behavior (but not stack overflows) when I use alloca() instead  
 of heap
 as an optimization, but when I disable this optimization, everything  
 seems to
 work.  I do know that several threads are likely calling alloca() at the  
 same
 time and with requests large enough that their stacks might need to be  
 expanded.

 At first, I thought this was just a symptom of a subtle race condition,  
 but I
 tried inserting sleep statements and synchronized blocks in various  
 places
 around the alloca() calls to change the timing of things and the  
 conclusion is
 the same:  malloc() works, alloca() doesn't.

You are probably misusing alloca (e.g. returning it from a function) or  
overwriting the stack space in some other way. This is strange otherwise.  
I don't think it is thread-unsafe since it doesn't access any global state.

Is the problematic source code available for inspection online?

btw, alloca is implemented in druntime\src\compiler\dmd\alloca.d

dsimcha <dsimcha yahoo.com> writes:

== Quote from Denis Koroskin (2korden gmail.com)'s article
 On Sun, 25 Oct 2009 03:34:24 +0300, dsimcha <dsimcha yahoo.com> wrote:
 Does anyone know if alloca() is by some chance not thread safe?  I'm
 working
 on improving my parallelization library and I keep running into all
 kinds of
 erratic behavior (but not stack overflows) when I use alloca() instead
 of heap
 as an optimization, but when I disable this optimization, everything
 seems to
 work.  I do know that several threads are likely calling alloca() at the
 same
 time and with requests large enough that their stacks might need to be
 expanded.

 At first, I thought this was just a symptom of a subtle race condition,
 but I
 tried inserting sleep statements and synchronized blocks in various
 places
 around the alloca() calls to change the timing of things and the
 conclusion is
 the same:  malloc() works, alloca() doesn't.

 You are probably misusing alloca (e.g. returning it from a function) or
 overwriting the stack space in some other way. This is strange otherwise.
 I don't think it is thread-unsafe since it doesn't access any global state.
 Is the problematic source code available for inspection online?
 btw, alloca is implemented in druntime\src\compiler\dmd\alloca.d

Yep, you're right.  There was a very subtle and interesting bug in my code. 
It's
too complicated to explain here, but suffice to say I was escaping stuff in a
pretty subtle way.