Simultaneous access to memory
in [Hardware]
|
From: Peter Olcott on 6 Apr 2010 19:54 "Paul" <nospam(a)needed.com> wrote in message news:hpgg0i$am6$1(a)news.eternal-september.org... > Peter Olcott wrote: >> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >> news:zuWdncZMA8wIJibWnZ2dnUVZ_rCdnZ2d(a)giganews.com... >>> "Sjouke Burry" <burrynulnulfour(a)ppllaanneett.nnll> wrote >>> in message >>> news:4bbbabc4$0$14122$703f8584(a)textnews.kpn.nl... >>>> Peter Olcott wrote: >>>>> What happens when two processes access memory at >>>>> literally the same time, with one reading and another >>>>> writing, does the read or the write get mangled? I >>>>> know the whole semaphore lock stuff, I want to know >>>>> what happens when one skips this step. >>>> Skip that step and you have a pile of junk instead of a >>>> computer. >>> I am taking this informal message to mean: >>> On ANY given hardware platform, a simultaneous read >>> operation interferes with a write operation such that >>> the write operation is garbled. >>> > > The read or the write will not be mangled. Operations are > atomic enough, to complete, and all you have to worry > about from a programming perspective, is whether the > order they complete in matters or not. > > If a read-modify-write instruction is involved, that is > atomic enough to complete, without being snipped in half. > The benefit of using an actual RMW type instruction on the > computer, is the processor takes care of it being atomic. > The processor won't allow an RMW to be split in half. > > http://en.wikipedia.org/wiki/Read-modify-write > > Paul Great now I have a fast way to trigger my preemptive scheduling. Will it work the way that you suggest on all modern hardware?
From: Paul on 6 Apr 2010 23:53 Peter Olcott wrote: > "Paul" <nospam(a)needed.com> wrote in message > news:hpgg0i$am6$1(a)news.eternal-september.org... >> Peter Olcott wrote: >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>> news:zuWdncZMA8wIJibWnZ2dnUVZ_rCdnZ2d(a)giganews.com... >>>> "Sjouke Burry" <burrynulnulfour(a)ppllaanneett.nnll> wrote >>>> in message >>>> news:4bbbabc4$0$14122$703f8584(a)textnews.kpn.nl... >>>>> Peter Olcott wrote: >>>>>> What happens when two processes access memory at >>>>>> literally the same time, with one reading and another >>>>>> writing, does the read or the write get mangled? I >>>>>> know the whole semaphore lock stuff, I want to know >>>>>> what happens when one skips this step. >>>>> Skip that step and you have a pile of junk instead of a >>>>> computer. >>>> I am taking this informal message to mean: >>>> On ANY given hardware platform, a simultaneous read >>>> operation interferes with a write operation such that >>>> the write operation is garbled. >>>> >> The read or the write will not be mangled. Operations are >> atomic enough, to complete, and all you have to worry >> about from a programming perspective, is whether the >> order they complete in matters or not. >> >> If a read-modify-write instruction is involved, that is >> atomic enough to complete, without being snipped in half. >> The benefit of using an actual RMW type instruction on the >> computer, is the processor takes care of it being atomic. >> The processor won't allow an RMW to be split in half. >> >> http://en.wikipedia.org/wiki/Read-modify-write >> >> Paul > > Great now I have a fast way to trigger my preemptive > scheduling. > Will it work the way that you suggest on all modern > hardware? I don't know when it was introduced. Maybe your programming environment has a primitive, and it takes care of the details ? Paul
From: Peter Olcott on 7 Apr 2010 10:13 "Paul" <nospam(a)needed.com> wrote in message news:hpgvkn$7mt$1(a)news.eternal-september.org... > Peter Olcott wrote: >> "Paul" <nospam(a)needed.com> wrote in message >> news:hpgg0i$am6$1(a)news.eternal-september.org... >>> Peter Olcott wrote: >>> If a read-modify-write instruction is involved, that is >>> atomic enough to complete, without being snipped in >>> half. >>> The benefit of using an actual RMW type instruction on >>> the >>> computer, is the processor takes care of it being >>> atomic. >>> The processor won't allow an RMW to be split in half. >>> >>> http://en.wikipedia.org/wiki/Read-modify-write >>> >>> Paul >> >> Great now I have a fast way to trigger my preemptive >> scheduling. >> Will it work the way that you suggest on all modern >> hardware? > > I don't know when it was introduced. > > Maybe your programming environment has a primitive, and it > takes care of the details ? No, not at all. The reason that I asked this question is so that I would know the limits of the degree that I could enhance the behavior of the operating system. As long as one process reading a memory location does not ever mangle another process writing to this location, even if the read may get mangled data when it occurs at the exact same moment as the write, then I am good to go. It would be even better if the read never gets mangled too. It looks like you are saying that I can count on both of these behaviors. > > Paul >
From: Paul on 7 Apr 2010 13:54 Peter Olcott wrote: > "Paul" <nospam(a)needed.com> wrote in message > news:hpgvkn$7mt$1(a)news.eternal-september.org... >> Peter Olcott wrote: >>> "Paul" <nospam(a)needed.com> wrote in message >>> news:hpgg0i$am6$1(a)news.eternal-september.org... >>>> Peter Olcott wrote: > >>>> If a read-modify-write instruction is involved, that is >>>> atomic enough to complete, without being snipped in >>>> half. >>>> The benefit of using an actual RMW type instruction on >>>> the >>>> computer, is the processor takes care of it being >>>> atomic. >>>> The processor won't allow an RMW to be split in half. >>>> >>>> http://en.wikipedia.org/wiki/Read-modify-write >>>> >>>> Paul >>> Great now I have a fast way to trigger my preemptive >>> scheduling. >>> Will it work the way that you suggest on all modern >>> hardware? >> I don't know when it was introduced. >> >> Maybe your programming environment has a primitive, and it >> takes care of the details ? > > No, not at all. The reason that I asked this question is so > that I would know the limits of the degree that I could > enhance the behavior of the operating system. > > As long as one process reading a memory location does not > ever mangle another process writing to this location, even > if the read may get mangled data when it occurs at the exact > same moment as the write, then I am good to go. It would be > even better if the read never gets mangled too. It looks > like you are saying that I can count on both of these > behaviors. > I don't think you have anything to worry about, with respect to memory based operations. If you want to create a semaphore, there might be a construct in the language you're using, which makes that possible using only the high level language. If it wasn't supported directly by the language, or a library provided for such things, then you can inject assembler code into your high level source, and do it that way. Otherwise, there might not be a direct mapping from a line of C/C++ code and say, a Test and Set instruction on the x86 processor. People can and do inject assembler into their programs, but when doing so, they need a damn good reason for doing so (think of the portability issues). If there is already a high level primitive, a library somewhere that does such things, then someone else already solved any portability issues for you. Paul
From: Peter Olcott on 7 Apr 2010 14:38
"Paul" <nospam(a)needed.com> wrote in message news:hpigs7$l5b$1(a)news.eternal-september.org... > Peter Olcott wrote: >> "Paul" <nospam(a)needed.com> wrote in message >> news:hpgvkn$7mt$1(a)news.eternal-september.org... >>> Peter Olcott wrote: >>>> "Paul" <nospam(a)needed.com> wrote in message >>>> news:hpgg0i$am6$1(a)news.eternal-september.org... >>>>> Peter Olcott wrote: >> >> As long as one process reading a memory location does not >> ever mangle another process writing to this location, >> even if the read may get mangled data when it occurs at >> the exact same moment as the write, then I am good to go. >> It would be even better if the read never gets mangled >> too. It looks like you are saying that I can count on >> both of these behaviors. >> > > I don't think you have anything to worry about, with > respect to > memory based operations. > > If you want to create a semaphore, there might be a > construct > in the language you're using, which makes that possible > using > only the high level language. If it wasn't supported > directly > by the language, or a library provided for such things, > then > you can inject assembler code into your high level source, > and > do it that way. Otherwise, there might not be a direct > mapping > from a line of C/C++ code and say, a Test and Set > instruction > on the x86 processor. People can and do inject assembler > into > their programs, but when doing so, they need a damn good > reason > for doing so (think of the portability issues). If there > is already > a high level primitive, a library somewhere that does such > things, then someone else already solved any portability > issues for you. > > Paul The OS invariably provides these services as function calls. |