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