www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Sharing unlocked, unchanging data between threads?

reply Chris Williams <aahz seanet.com> writes:
I'm writing a fairly large, multithreaded application and some part
of it is causing periodic access errors.

Say that I have an associative array like:

uint[ char[] ] nameToId;

If I set all values before I start my threads going and never change
anything after that point -- all access is read only -- is there any
way that having multiple threads access it at the same time would
mess anything up? I'm doing this in several places as locking a
read-only data structure doesn't strike me as something which should
be necessary. I don't know what D's associative arrays look like
internally though, so perhaps it is dangerous to do. It would be a
major hassle to port it all over to locking everything, to test if
it fixes the problem. So, hopefully someone can say whether this is
worth checking.
Aug 10 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Aug 2010 13:45:03 -0400, Chris Williams <aahz seanet.com> wrote:

 I'm writing a fairly large, multithreaded application and some part
 of it is causing periodic access errors.

 Say that I have an associative array like:

 uint[ char[] ] nameToId;

 If I set all values before I start my threads going and never change
 anything after that point -- all access is read only -- is there any
 way that having multiple threads access it at the same time would
 mess anything up? I'm doing this in several places as locking a
 read-only data structure doesn't strike me as something which should
 be necessary. I don't know what D's associative arrays look like
 internally though, so perhaps it is dangerous to do. It would be a
 major hassle to port it all over to locking everything, to test if
 it fixes the problem. So, hopefully someone can say whether this is
 worth checking.
I don't see any reason why you'd need to lock it. It should not be modified unless you change/insert a value or remove one. It's likely something else causing the issue. -Steve
Aug 10 2010
parent awishformore <awishformore nospam.plz> writes:
On 10/08/2010 20:01, Steven Schveighoffer wrote:
 On Tue, 10 Aug 2010 13:45:03 -0400, Chris Williams <aahz seanet.com> wrote:

 I'm writing a fairly large, multithreaded application and some part
 of it is causing periodic access errors.

 Say that I have an associative array like:

 uint[ char[] ] nameToId;

 If I set all values before I start my threads going and never change
 anything after that point -- all access is read only -- is there any
 way that having multiple threads access it at the same time would
 mess anything up? I'm doing this in several places as locking a
 read-only data structure doesn't strike me as something which should
 be necessary. I don't know what D's associative arrays look like
 internally though, so perhaps it is dangerous to do. It would be a
 major hassle to port it all over to locking everything, to test if
 it fixes the problem. So, hopefully someone can say whether this is
 worth checking.
I don't see any reason why you'd need to lock it. It should not be modified unless you change/insert a value or remove one. It's likely something else causing the issue. -Steve
That and: you should probably declare it as immutable. /Max
Aug 10 2010
prev sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday, August 10, 2010 10:45:03 Chris Williams wrote:
 I'm writing a fairly large, multithreaded application and some part
 of it is causing periodic access errors.
 
 Say that I have an associative array like:
 
 uint[ char[] ] nameToId;
 
 If I set all values before I start my threads going and never change
 anything after that point -- all access is read only -- is there any
 way that having multiple threads access it at the same time would
 mess anything up? I'm doing this in several places as locking a
 read-only data structure doesn't strike me as something which should
 be necessary. I don't know what D's associative arrays look like
 internally though, so perhaps it is dangerous to do. It would be a
 major hassle to port it all over to locking everything, to test if
 it fixes the problem. So, hopefully someone can say whether this is
 worth checking.
Well, unless it's declared shared, it's going to be thread-local, and then each thread is going to have their own copy. Now, if it were declared shared and you never changed it after initially setting all of its values, then you shouldn't have any problems as far as I'm aware. Just accessing an associative array shouldn't change it. - Jonathan M Davis
Aug 10 2010
next sibling parent reply Chris Williams <aahz seanet.com> writes:
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 Well, unless it's declared shared, it's going to be thread-local,
and then each
 thread is going to have their own copy. Now, if it were declared
shared and you
 never changed it after initially setting all of its values, then you
shouldn't
 have any problems as far as I'm aware. Just accessing an associative
array
 shouldn't change it.
 - Jonathan M Davis
I'm using D 1.0. I don't believe it has a "shared" keyword. But, globals are shared as well, I presume.
Aug 10 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Aug 2010 14:53:18 -0400, Chris Williams <aahz seanet.com> wrote:

 == Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 Well, unless it's declared shared, it's going to be thread-local,
and then each
 thread is going to have their own copy. Now, if it were declared
shared and you
 never changed it after initially setting all of its values, then you
shouldn't
 have any problems as far as I'm aware. Just accessing an associative
array
 shouldn't change it.
 - Jonathan M Davis
I'm using D 1.0. I don't believe it has a "shared" keyword. But, globals are shared as well, I presume.
What runtime are you using, Tango or Phobos? Because Phobos' D1 runtime has not had any TLC for a while. It's quite possible there are some lingering bugs. -Steve
Aug 11 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-10 20:40, Jonathan M Davis wrote:
 On Tuesday, August 10, 2010 10:45:03 Chris Williams wrote:
 I'm writing a fairly large, multithreaded application and some part
 of it is causing periodic access errors.

 Say that I have an associative array like:

 uint[ char[] ] nameToId;

 If I set all values before I start my threads going and never change
 anything after that point -- all access is read only -- is there any
 way that having multiple threads access it at the same time would
 mess anything up? I'm doing this in several places as locking a
 read-only data structure doesn't strike me as something which should
 be necessary. I don't know what D's associative arrays look like
 internally though, so perhaps it is dangerous to do. It would be a
 major hassle to port it all over to locking everything, to test if
 it fixes the problem. So, hopefully someone can say whether this is
 worth checking.
Well, unless it's declared shared, it's going to be thread-local, and then each thread is going to have their own copy. Now, if it were declared shared and you never changed it after initially setting all of its values, then you shouldn't have any problems as far as I'm aware. Just accessing an associative array shouldn't change it. - Jonathan M Davis
I though immutable was supposed to be implicitly shared with no need for locks or read-write barriers (or what they're called). -- /Jacob Carlborg
Aug 10 2010
parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday, August 10, 2010 11:54:06 Jacob Carlborg wrote:
 I though immutable was supposed to be implicitly shared with no need for
 locks or read-write barriers (or what they're called).
Ah. I have no clue that D1 does. I only use D2. There's obviously nothing wrong with posting D1 questions here, but most of the discussion and questions around here are for D2, so it's probably a good idea to indicate that you're using D1 when asking a D1-related question. - Jonathan M Davis
Aug 10 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-10 23:53, Jonathan M Davis wrote:
 On Tuesday, August 10, 2010 11:54:06 Jacob Carlborg wrote:
 I though immutable was supposed to be implicitly shared with no need for
 locks or read-write barriers (or what they're called).
Ah. I have no clue that D1 does. I only use D2. There's obviously nothing wrong with posting D1 questions here, but most of the discussion and questions around here are for D2, so it's probably a good idea to indicate that you're using D1 when asking a D1-related question. - Jonathan M Davis
Oh, was the question about D1? I didn't get that. -- /Jacob Carlborg
Aug 11 2010
parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, August 11, 2010 02:36:55 Jacob Carlborg wrote:
 On 2010-08-10 23:53, Jonathan M Davis wrote:
 On Tuesday, August 10, 2010 11:54:06 Jacob Carlborg wrote:
 I though immutable was supposed to be implicitly shared with no need for
 locks or read-write barriers (or what they're called).
Ah. I have no clue that D1 does. I only use D2. There's obviously nothing wrong with posting D1 questions here, but most of the discussion and questions around here are for D2, so it's probably a good idea to indicate that you're using D1 when asking a D1-related question. - Jonathan M Davis
Oh, was the question about D1? I didn't get that.
LOL. Apparently, I managed to respond to entirely the wrong post. I intended to respond to Chris Williams' post that he was using D1, not yours. I have no idea how I did that... In any case, I posted to the right thread but the wrong post. So, yes, apparently he's using D1, but he never said that, so at least some of us (if not all of us) assumed that he was talking about D2. - Jonathan M Davis
Aug 11 2010