Wed Dec 4 02:16:12 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-04-01

LEARN

2024-12-04 | 2024-11-04 | 2024-10-04 | 2024-09-04 | 2024-08-04 | 2024-07-04 | 2024-06-04 | 2024-05-04 | 2024-04-04 | 2024-03-04 | 2024-02-04 | 2024-01-04 | 2023-12-04 | 2023-11-04 | 2023-10-04 | 2023-09-04 | 2023-08-04 | 2023-07-04 | 2023-06-04 | 2023-05-04 | 2023-04-04 | 2023-03-04 | 2023-02-04 | 2023-01-04 | 2022-12-04 | 2022-11-04 | 2022-10-04 | 2022-09-04 | 2022-08-04 | 2022-07-04 | 2022-06-04 | 2022-05-04 | 2022-04-04 | 2022-03-04 | 2022-02-04 | 2022-01-04 | 2021-12-04 | 2021-11-04 | 2021-10-04 | 2021-09-04 | 2021-08-04 | 2021-07-04 | 2021-06-04 | 2021-05-04 | 2021-04-04 | 2021-03-04 | 2021-02-04 | 2021-01-04 | 2020-12-04 | 2020-11-04 | 2020-10-04 | 2020-09-04 | 2020-08-04 | 2020-07-04 | 2020-06-04 | 2020-05-04 | 2020-04-04 | 2020-03-04 | 2020-02-04 | 2020-01-04 | 2019-12-04 | 2019-11-04 | 2019-10-04 | 2019-09-04 | 2019-08-04 | 2019-07-04 | 2019-06-04 | 2019-05-04 | 2019-04-04 | 2019-03-04 | 2019-02-04 | 2019-01-04 | 2018-12-04 | 2018-11-04 | 2018-10-04 | 2018-09-04 | 2018-08-04 | 2018-07-04 | 2018-06-04 | 2018-05-04 | 2018-04-04 | 2018-03-04 | 2018-02-04 | 2018-01-04 | 2017-12-04 | 2017-11-04 | 2017-10-04 | 2017-09-04 | 2017-08-04 | 2017-07-04 | 2017-06-04 | 2017-05-04 | 2017-04-04 | 2017-03-04 | 2017-02-04 | 2017-01-04 | 2016-12-04 | 2016-11-04 | 2016-10-04 | 2016-09-04 | 2016-08-04 | 2016-07-04 | 2016-06-04 | 2016-05-04 | 2016-04-04 | 2016-03-04 | 2016-02-04 | 2016-01-04 | 2015-12-04 | 2015-11-04 | 2015-10-04 | 2015-09-04 | 2015-08-04 | 2015-07-04 | 2015-06-04 | 2015-05-04 | 2015-04-04 | 2015-03-04 | 2015-02-04 | 2015-01-04 | 2014-12-04 | 2014-11-04 | 2014-10-04

Key: Value:

Key: Value:

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
>

  1. 2015-04-01 Ruben <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] external paths
  2. 2015-04-01 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] omp pthread madness
  3. 2015-04-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Fw: Perl Developer / Linux SysAdmin Opportunities in South Florida
  4. 2015-04-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: omp pthread madness
  5. 2015-04-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: omp pthread madness
  6. 2015-04-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: [New discussion] which technologies/skills are good to have
  7. 2015-04-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: omp pthread madness
  8. 2015-04-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: Depths and heights
  9. 2015-04-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: Kernel thread scheduling
  10. 2015-04-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: Kernel thread scheduling
  11. 2015-04-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] BASh Shell Scripting
  12. 2015-04-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Chapter 5 Monitor
  13. 2015-04-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: [Perlweekly] #194 - The CPAN PR Challenge Now Has a Mini-Me!
  14. 2015-04-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Kernel Hacking Resources
  15. 2015-04-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Invitation: Vintage Computer Festival
  16. 2015-04-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] hashing slots sizes
  17. 2015-04-15 Ruben <mrbrklyn-at-panix.com> Re: [LIU Comp Sci] BASh Shell Scripting
  18. 2015-04-15 Maneesh Kongara <maneeshkongara-at-gmail.com> Re: [LIU Comp Sci] BASh Shell Scripting
  19. 2015-04-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Monday: Join 121 HackerNestologists at "HackerNest NYC April
  20. 2015-04-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: You're confirmed for: NYLUG Open hacker hours
  21. 2015-04-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Hash Tables Examples
  22. 2015-04-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: hashing quadradic probes
  23. 2015-04-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] [ruben-at-mrbrklyn.com: Re: Heap Management Problem]
  24. 2015-04-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Re: virtualbox
  25. 2015-04-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] linsched
  26. 2015-04-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] scheduler project thus far
  27. 2015-04-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Come Sunday Morning
  28. 2015-04-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Kernel Scheduling Project
  29. 2015-04-17 Ruben <ruben.safir-at-my.liu.edu> Subject: [LIU Comp Sci] more advanced coding musings ...
  30. 2015-04-19 Tony Genao <tony.genao-at-my.liu.edu> Re: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  31. 2015-04-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  32. 2015-04-19 Tony Genao <tony.genao-at-my.liu.edu> Re: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  33. 2015-04-19 Ruben <mrbrklyn-at-panix.com> Re: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  34. 2015-04-19 Tony Genao <tony.genao-at-my.liu.edu> Re: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  35. 2015-04-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: [NYLXS - HANGOUT] Summers Here
  36. 2015-04-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: The more I learn the less I know
  37. 2015-04-22 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Re: wait queues semiphores kernel implementations
  38. 2015-04-22 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] linux locks and mutex
  39. 2015-04-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Re: Kernel Scheduler and wiat queues
  40. 2015-04-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Kernel Scheduling and wait queues
  41. 2015-04-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: OS Cpt 9 27 question
  42. 2015-04-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: Tomorrow: You and 30 other Flatirons are going to "Flatiron
  43. 2015-04-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: DMCA exemption commenting process broken beyond repair
  44. 2015-04-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Do you have notes for this question
  45. 2015-04-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Professional Troll job available
  46. 2015-04-29 Ruben <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Re: DMCA exemption commenting process broken beyond repair

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!