random.gauss vs. random.normalvariate

[Dave Angel]

John Haggerty wrote:
> On Sat, Aug 15, 2009 at 7:23 PM, Dennis Lee Bieber <wlfraed at ix.netcom.com>wrote:
>
>   
>> On Sat, 15 Aug 2009 14:34:36 -0600, John Haggerty <bouncyinc at gmail.com>
>> declaimed the following in gmane.comp.python.general:
>>
>>     
>>> What does the term "thread safe" mean exactly. I never had to program
>>>       
>> with
>>     
>>> "threads" before
>>>       
>>         That, part way through the logic of the function, control could be
>> switched to a different thread which call the same function... This
>> second call would change some of the internal values and may then be
>> preempted and control returned to the first thread, which continues the
>> rest of the function with different values then it had when first
>> preempted.
>>
>>        A very contrived example, untested of course, consider it
>> pseudo-code...
>>
>> startt = None
>>
>> def atimer():
>>        global startt
>>        startt = time.time()
>>        time.sleep(5)
>>        print time.time() - startt
>>
>> t1 = threading.thread(atimer)
>> t2 = threading.thread(atimer)
>> t1.start()
>> t2.start()
>>
>> Say t1 gets all the way up to the sleep call, and (since sleep is a
>> releasing call), t2 then starts. t2 changes the value of startt; and
>> sleeps... both sleep and presuming the resolution is fine enough, t1
>> resumes, and  prints a delta time that is incorrect -- it is printing
>> the time difference from when t2 started to sleep, not from when t1
>> started to sleep.
>> --
>>        Wulfraed         Dennis Lee Bieber               KD6MOG
>>        wlfraed at ix.netcom.com   HTTP://wlfraed.home.netcom.com/
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>     
>
> Interesting so it seems that the compiler(c/c++)interpreter(perl,
> python)/vm(java) doesn't do this?
>
>   
It is impossible for a language, vm, or operating system to avoid 
threading problems without the programmer's help, except by trivial 
means (eg. preventing you from having them at all).

The power of threading is entirely tied up with the features the 
environment gives to the developer, and those features come with a risk.

At one extreme is the CP/M model.  You start a new program only when you 
finish the previous one.  So the only communication between them is a 
file the first one leaves behind, that the second can look at.

Next is separate processes.  If you launch a second process, by default, 
they're independent, and not likely to get into trouble.  But you can 
build pipes or shared memory, or sockets between them, and then you have 
to worry about race conditions.

Next is threads, within a single process.  At this point, you can share 
(global) variables between them, or you can have objects known to both 
when the thread is launched.  The system cannot tell which ones are 
deliberate and which ones are accidental.  So a language might give 
extra keywords to tell the compiler that certain things should be 
protected in certain ways.  Or it might give a way to declare a 
"per-thread global" that acts like a global to each thread, but is 
actually two independent variables from the process point of view.

The only real reason threads are singled out is it's easier to collide 
by mistake.  But that's also what makes it efficient to "collide" on 
purpose.

DaveA