On 04/11/2011 11:41 AM, mark florisson wrote:
On 11 April 2011 11:10, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no> wrote:
On 04/11/2011 10:45 AM, mark florisson wrote:
On 5 April 2011 22:29, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no>
wrote:
I've done a pretty major revision to the prange CEP, bringing in a lot of
the feedback.
Thread-private variables are now split in two cases:
i) The safe cases, which really require very little technical knowledge
->
automatically inferred
ii) As an advanced feature, unsafe cases that requires some knowledge of
threading -> must be explicitly declared
I think this split simplifies things a great deal.
Can't we obsolete the declaration entirely by assigning to variables
that need to have firstprivate behaviour inside the with parallel
block? Basically in the same way the scratch space is used. The only
problem with that is that it won't be lastprivate, so the value will
be undefined after the parallel block (but not after the worksharing
loop).
cdef int myvariable
with nogil, parallel:
myvariable = 2
for i in prange(...):
use myvariable
maybe assign to myvariable
# myvariable is well-defined here
# myvariable is not well-defined here
If you still desperately want lastprivate behaviour you can simply
assign myvariable to another variable in the loop body.
I don't care about lastprivate, I don't think that is an issue, as you say.
My problem with this is that it means going into an area where possibly
tricky things are implicit rather than explicit. I also see this as a rather
special case that will be seldomly used, and implicit behaviour is more
difficult to justify because of that.
Indeed, I actually considered if we should support firstprivate at
all, as it's really about "being firstprivate and lastprivate".
Without any declaration, you can have firstprivate or lastprivate, but
not both :) So I agree that supporting such a (probably) uncommon case
is better left explicit. On the other hand it seems silly to have
support for such a weird case.
Well, I actually need to do the per-thread cache thing I described in
the CEP in my own codes, so it's not *that* special; it'd be nice to
support it.
OTOH I *could* work around it by having an array of scalars
cdef int[:] old_ell = int[:numthreads]()
...
if old_ell[threadid()] != ell: ...
So I guess, it's at least on the bottom of list of priorities in that CEP.
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
