From the intel manual: 24319202 (systems programming). Chapter 7
Multiple-Processor management.
“The Intel386™, Intel486™, Pentium ® , and P6 family processors guarantee that the following
basic memory operations will always be carried out atomically:
• Reading or writing a byte.
• Reading or writing a word aligned on a 16-bit boundary.
• Reading or writing a doubleword aligned on a 32-bit boundary.”
This means that the writting processor garanties that the write
operation will complete before another processor can do a read.
Example:
Processor 1:
mov MyByte, 0
mov MyByte, 0xFF ; This instruction is simultanious
Processor 2:
mov al, MyByte ; This instruction is simultanious with processor 1
AL would on processor 2 after execution always have the value 0 or
0xFF. It would never be a half written bit pattern.
regards,
Anders
Friday, May 18, 2001, 1:47:27 PM, you wrote:
rs> Does that mean that on intel arch, single bytes are always protected against
rs> simultaneous operations? How about this structure :
rs> typedef struct
rs> {
rs> boolean a;
rs> boolean b;
rs> int c,
rs> boolean d;
rs> char e
rs> }myStruct;
rs> will myStruct.a, myStruct.b, myStruct.d and myStrcut.e will always be
rs> protected for synchronisation or its only dependant on the total size of the
rs> strcuture?
rs> In fact I have such a big struct and my boolean var is a part of that
rs> structure and this struct is always passed as pointer.
rs> thanks
>Good point. Besides on intel architecture read/write on single bytes
>are garantied atomic and bools are usually just single bytes. Unless
>you’ll be passing a long a pointer or smething as well, there is no
>need for synchronization.
>
>Anders
>
>Friday, May 18, 2001, 11:49:49 AM, you wrote:
>
>RM> Fine (sort of) then your reader thread has a loop, and as part of that
>loop
>RM> you read your boolean. Either you read it before or after your writer
>thread
>RM> writes it. Interlocking is not going to help here as it remains a fact
>that
>RM> either you read the value before it is written, or you read it after.
>If
>RM> your reader reads before it is written, well then next time around it
>will
>RM> read it after it is written. You do some dma work, read your flag,
>repeat
>RM> until asked to die.
>
>
>RM> Having a thread that is continuously busy, even when it perhaps has
>nothing
>RM> to do, is not such a good idea.
rs> _________________________________________________________________________
rs> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
rs> —
rs> You are currently subscribed to ntdev as: xxxxx@flaffer.com
rs> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
–
Best regards,
Anders mailto:xxxxx@flaffer.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com