Page 1 of 1

Mutex locking and unlocking with nmodl

Posted: Fri Dec 10, 2010 6:27 pm
by vgoudar
While the common approach to calculating synaptic release is at the post-synaptic terminal, in my case all synapses with pre-synaptic terminals in a given soma have the same release calculation. Therefore, the complexity of computation is greatly reduced if I can have most of those computations performed at the pre-synaptic soma and then originate a netcon to the post-synaptic point processes to access the state variables via pointers. Since pointers arent thread safe, and for good reason, is it possible to use a mutex lock and unlock mechanism in nmodl. That way, I can still use pointers and declare the synaptic point process THREADSAFE while ensuring that the accesses to the state variables are always accurate. The source code (C files) do seem to indicate that such a thing may be possible. If so, can I please be referred to an example?

Re: Mutex locking and unlocking with nmodl

Posted: Sat Dec 11, 2010 5:35 pm
by hines
You are in luck in regard to thread safety using MUTEXLOCK in a mod file. All instances use the same lock
extern pthread_mutex_t* _nmodlmutex;

However I'm not positive there will not be a performance problem. You should try it out and see how much time is spent waiting for a lock to
be released. You can time a simulation with and without the locks. Just realize that without them worng results may occur at more or less
frequent intervals.

Re: Mutex locking and unlocking with nmodl

Posted: Sat Dec 11, 2010 5:47 pm
by hines
I realize that since I don't know the details of your presynaptic and postsynaptic calculations, I can't
be certain that you need locks. Or that the computation is valid even if you use locks.
Locks do not impose an order on what gets done. Just that only one thread at a time
executes within a locked region.

Re: Mutex locking and unlocking with nmodl

Posted: Mon Dec 13, 2010 11:03 pm
by vgoudar
Yes, you make a good point about ordering of the events. So, assuming I limit my model to global time, why wouldnt pointers be thread safe if they share the process's address space? I guess it doesnt make a difference if I use mutexes because, even if I run with a single thread the events may still be executed in any order allowing two neurons trying to access a pointer on a third neuron to get inconsistent readings of the pointer value assuming the three neurons calculations correspond to different events set to occur at the same time. If this is the case, there shouldnt be a relationship between a model's usage of POINTERs and its threadsafety. Please advise?