digitalmars.D.learn - Sharing unlocked, unchanging data between threads?
- Chris Williams <aahz seanet.com> Aug 10 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Aug 10 2010
- awishformore <awishformore nospam.plz> Aug 10 2010
- Jonathan M Davis <jmdavisprog gmail.com> Aug 10 2010
- Chris Williams <aahz seanet.com> Aug 10 2010
- Jacob Carlborg <doob me.com> Aug 10 2010
- Jacob Carlborg <doob me.com> Aug 11 2010
- Jonathan M Davis <jmdavisprog gmail.com> Aug 10 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Aug 11 2010
- Jonathan M Davis <jmdavisprog gmail.com> Aug 11 2010
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
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
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
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
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s articleWell, unless it's declared shared, it's going to be thread-local,
thread is going to have their own copy. Now, if it were declared
never changed it after initially setting all of its values, then you
have any problems as far as I'm aware. Just accessing an associative
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
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
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
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
On Tue, 10 Aug 2010 14:53:18 -0400, Chris Williams <aahz seanet.com> wrote:== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s articleWell, unless it's declared shared, it's going to be thread-local,
thread is going to have their own copy. Now, if it were declared
never changed it after initially setting all of its values, then you
have any problems as far as I'm aware. Just accessing an associative
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
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









awishformore <awishformore nospam.plz> 