"normrand is not thread safe"

[Bill Connelly]

A) I'm being told normrand is not thread safe. Is there anything I can do to make it so? Are any of the other random variables threadsafe?

B) What is the logic behind this? In my head you could things could be threadsafe so long as you were essentially running completely independent equations of different threads. How does having a random number break this?

[ted]

Random values described by the normal distribution are generated by an algorithm that produces two values at once. One value is returned, and the other is saved in a buffer until the next time repick() is called. This is what makes normrand not threadsafe. Some programmers work around this by writing C code that deliberately throws away the second value, but that's a nonstandard hack--it's bad for code portability and reproducibility. A sound approach is to closely associate each "thing" that needs a sequence of random numbers with its own random number generator. Then multithreaded execution will be OK since A will be paired with its own random number generator in the same thread, and likewise for B. Maybe if you could describe how you want to use the normal distribution, I could provide an example of how to do this.

[Bill Connelly]

Just a very simple Random Current generator

Code: Select all

NEURON {
	POINT_PROCESS Inoise
	RANGE tau, amp
	RANGE new_seed
	NONSPECIFIC_CURRENT i
}

PARAMETER {
  dt    //ANOTHER QUESTION, DO I NEED THIS HERE?????
  tau = 50 (ms)
  amp = 0.001 (nA)
}

ASSIGNED {
  i
}

INITIAL {
  i = 0
}

BREAKPOINT {
   i = i - (dt*i)/tau + dt*amp*normrand(0,1)
}

PROCEDURE new_seed(seed) {		: called with an incrementing argument each time init() is called
	set_seed(seed)
}

[ted]

How about something like the "gaussian noise" source described in this post?
http://www.neuron.yale.edu/phpBB/viewto ... 986#p12288
I should probably make some minor changes so it uses Random123; it would then be easier to use (for one thing, the RandomStream object would no longer be needed).