[Scilab-Dev] [SEP] Reentrancy detection in loop

[bernard.hugueney at scilab.org]

On Fri, 2 Oct 2009 14:08:55 +0200 (CEST), "Vincent Lejeune"
<vincent.lejeune at institutoptique.fr> wrote:
> Hi,
> 
> I writted this SEP with Scilab 6 in mind. It deals with the detection of
> reentrancy inside a loop to use the simd feature provided by hardware
> (like GPU) or network topology. I think it's an interesting idea, but
> quite difficult to put in place, so I think there will be some
> discussion afterward.
> 
> Regards,
> Vincent

Thanks for tackling this most important aspect!
I'd like to put forward two opinions on this subject of functions analysis
and annotations wrt parallelisation opportunities :

1°) As you noted, reentrancy is stronger than thread-safety, hence more
difficult to achieve. However, an important mean of parallelisation would
be multihtreading (i.e with OpenMP implementation). In this regard, I think
we should not restrict ourselves to a binary approach reentrant / unsafe
but consider : reentrant / mt-safe / unsafe (to enable the multi-thread
parallelisation of functions using locks and/or thread-local storage).
(Maybe we could be forward looking and also add a "pure" qualifier (à la
C++0x) even stronger than reentrant, to enable further optimizations such
as memoization, JIT constant folding etc.)

2°) While automatic analysis is important, it will be imperfect and must
be by pessimistic to be on the safe side. For this reason, I think it would
be useful to enable the developper to override the automatic analysis and
take full responsability by being explicit about the parallelisation
safety.
Dynamic compilation and link of functions implemented in C++/C/Fortran
should also enable such explicit anotation as they will be prime candidates
for parallelisation when used as callback in preformance sensitive
applications.

What is your opinion on these matters ?

Best regards,

Bernard