On Tue, Apr 5, 2011 at 4:52 AM, mark florisson
<markflorisso...@gmail.com> wrote:
> On 5 April 2011 12:51, Stefan Behnel <stefan...@behnel.de> wrote:
>> mark florisson, 04.04.2011 21:26:
>>>
>>> For clarity, I'll add an example:
>>>
>>> def f(np.ndarray[double] x, double alpha):
>>> cdef double s = 0
>>> cdef double tmp = 2
>>> cdef double other = 6.6
>>>
>>> with nogil:
>>> for i in prange(x.shape[0]):
>>> # reading 'tmp' makes it firstprivate in addition to
>>> lastprivate
>>> # 'other' is only ever read, so it's shared
>>> printf("%lf %lf %lf\n", tmp, s, other)
>>
>> So, adding a printf() to your code can change the semantics of your
>> variables? That sounds like a really bad design to me.
>
> I agree, I think we should refrain from the firstprivate() entirely,
> as it wouldn't have the same semantics as serial execution (as 'tmp'
> would have the original value with parallel execution and the value
> from previous iterations with serial execution). So basically we
> should allow reading of private variables only after they are assigned
> to in the loop body.
Unless I'm miss-understanding the meaning of firstprivate (it's
initialized per-thread, not per-iteration), for single-threaded
execution, it would have exactly the same semantics as serial
execution. As I mentioned before, if your code functions differently
for single or multiple threads, then it's incorrect. I think it's
natural that a parallel loop would behave like
tmp = global_value
if fork():
# do first half of the loop, with tmp starting as global_value
else:
# do last half of the loop, with tmp starting as global_value
# reduction magic
- Robert
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
