store addr(r),r1 // stores 2 to r *in memory* w = not(r,l) // since r *in memory* is still 0,
load r1,addr(l) // load l (value 2) into register r1 The reader's assignment r = l is given as the above assembly operations, for which the writer performs troublesome operations in between: r=0 w=1 l=2 // (given starting conditions) The notation and specify which thread is doing what. The first thread (the reader) would then overwrite this memory when storing from register to memory.Ĭonsider the following sequence of events. The problem in your case is that the register of one thread (say, the reader) could keep an intermediate value while another thread (writer) modifies memory. Where r1 is some register, addr(l) is the memory address of wherever l is stored, and addr(r) is the address of r. Store addr(r),r1 store register r1 to wherever r is kept So the assignment r = l would be something like the "pseudo-assembly": load r1,addr(l) load l from memory into register r1 However, threads must have their own stack and register states, otherwise they just wouldn't work.Īn assignment such as the reader's line r = l would first load a value from some memory location (wherever l is stored) into a register, then store this value to memory (wherever r is stored). Globals and heap memory are shared between threads of the same process, so this part is easy. I'm assuming that you would implement r, w, and l as variables in memory that would be visible to both threads. This introduces an intermediate state (the register) that could possibly mix things up in a multi-threaded situation such as this. there are no direct memory-to-memory operations). Most computers use a "load/store" architecture where values from memory must be moved to a register before being moved to another memory location (i.e. The difficulty is in how your pseudocode would be executed in hardware. The fundamental problem is that even variable assignment is not an atomic operation. I have just sent him an email to clarify this. I agree wiith you, to me pseudocode should be like more descriptive comments, however it seems he wants us to use C style pseudocode, like what I did above. You might mention it once as an additional comment the first time you used it, but that's about all.Interesting, thanks Salem. ) Would I have to include that in the pseudocode ? The for loop I would replace with a pseudo code line of say "search predefined apertures for a match", then an indented block of pseudo code to describe the inner detail of "matching apertures". Sscanf( buff, "%f", &exposure ) The idea being you could just paste your pseudo code into an empty source file, go through it putting /**/ comments around each line, then start filling in the details with actual code. Code: /* Prompt for and read exposure value */
0 kommentar(er)
