MESSAGE
| DATE | 2015-04-02 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Re: omp pthread madness
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Apr 2 13:12:00 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 78CE216116B; Thu, 2 Apr 2015 13:12:00 -0400 (EDT)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 66EA8161170; Thu, 2 Apr 2015 13:12:00 -0400 (EDT)
Delivered-To: learn-at-nylxs.com
Received: from l2mail1.panix.com (l2mail1.panix.com [166.84.1.75])
by mrbrklyn.com (Postfix) with ESMTP id EB9AD16116B;
Thu, 2 Apr 2015 13:11:35 -0400 (EDT)
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by l2mail1.panix.com (Postfix) with ESMTP id 129898705;
Thu, 2 Apr 2015 12:13:08 -0400 (EDT)
Received: from [10.0.0.19] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id A039A12A10;
Thu, 2 Apr 2015 12:08:05 -0400 (EDT)
Message-ID: <551D6965.5010007-at-panix.com>
Date: Thu, 02 Apr 2015 12:08:05 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: mohammed Ghriga , learn-at-nylxs.com,
hangout
Subject: [LIU Comp Sci] Re: omp pthread madness
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
On 04/02/2015 10:26 AM, Jens Thoms Toerring wrote:
> ruben wrote:
>> On Wed, 01 Apr 2015 10:04:59 +0000, Jens Thoms Toerring wrote:
>
>>> The obvious problem is that you have (at least) 2 threads which
>>> uncoordinatedly write into shared, global variables.
>
>> How is it uncoordinated. I couldn't think of anything that is shared
>> that would upset the final result.
>
> It is uncoordinated because it's unpredictable in which sequence
> the threads will access these global variables and, worse, they
> may do it at the same time.
>
> Are you aware of the 'sig_atomic_t' type in C? The reason
> for its existence is that reads from or writes to even
> something simple as an integer isn't "atomic", i.e. one
> thread may have updated parts of that integer (say one of
> the bytes it consists of) when another thread gets sche-
> duled and tries to read this integer which is now in some
> strange state. So the second thread will get some more or
> less random value instead of what the programmer expected.
> Or let's have thread 1 having started to update the integer,
> then thread 2 comes along, updates all of it and then we're
> back in thread 1 that writes the parts it hadn't got around
> to before. Result? A random value in memory. What's special
> about the 'sig_atomic_t' is that with that type this can't
> happen, you're guaranteed that a thread of execution can't
> be interupted while it writes or reads it.
>
> Now, if this already can happen with integers, it clearly isn't
> any better with floats or doubles. And your program assumes
> obviously that the random values you write into the 'workspace'
> have a well-definen upper limit (looks like it's 1). Unccor-
> dinated writes to the same location may result in values that
> doesn't satisfy this condition. And in other cases values
> may be smaller. You probably won't notice it, but it can
> happen and add some additional noise to the results of
> your calculations.
>
> Another place were things can go wrong is with your
> 'inside_the_circle' variable. There's a non-vanishing
> chance that, for the line
>
> inside_the_circle++;
>
> the following happens: thread 1 reads its value to increment
> it. Along comes thread 2 and possibly increments it several
> times before thread 1 gets to finish what it set out to do.
> Then it will increment ther value it had read and write it
> into memory, thereby destroying all the work the other thread
> had done in between.
>
> Or you may end up with a situation where the compiler
> optimizes your program in way that during the count_inside()
> function the value of 'inside_the_circle' is kept in a CPU
> register and only this copy is incremented. It's then only
> written out at the very end of the function. And then, when
> both threads run that function at the same time, they both
> increment their copy in the CPU register and write it out at
> the end, with the thread getting there last simply overwri-
> ting whatever any other thread had put there before.
>
> So you can't trust what this variable is set to when both
> threads are done with it.
>
> In any case, if you'd run your program several times with
> the same seed for the random generator you'll rather likely
> end up with different results. Your program has become in-
> deterministic with its result depending on subtle timing
> differences in how the threads get scheduled or access
> your global variables. That's something one tries to avoid
> like the plague.
> Regards, Jens
>
|
|
