multithreading on a multiprocessor system ( a bit OT )

multithreading on a multiprocessor system ( a bit OT )

[R. Sinoradzki]

Hi,
   I ask here, because I think it's probably a good place
to get some hints, links, papers or book recommendations.
I am absolutely new to multiprocessing. I only took a basic OS course
and did some practical training with NachOS ...

O.K my question:
Consider two modern processors that share some data and a lock.
The lock may be implemented with something like an atomic test-and-set
instruction. Now processor 'A' acquires the lock and works with the data.
Processor 'B' also wants to access the data, but internally reorders it's
instructions because the instructions seem independent from each other.
So 'B' might access the data without having the lock.
If it's a single processor system, reordering instructions in a way that
ensures that it looks 'as if' everything has been executed in the right order
might be easy, but in a multiprocessor system 'A' doesn't know 'B's state.

My idea is, that there are special instructions that prevent reordering in
this case, but would this be enough and what does really happen ?

bye, Ralf

Re: multithreading on a multiprocessor system ( a bit OT )

[Justin Carlson]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Wed, 2002-01-16 at 14:49, R. Sinoradzki wrote:
> O.K my question:
> Consider two modern processors that share some data and a lock.
> The lock may be implemented with something like an atomic test-and-set
> instruction. Now processor 'A' acquires the lock and works with the data.
> Processor 'B' also wants to access the data, but internally reorders it's
> instructions because the instructions seem independent from each other.
> So 'B' might access the data without having the lock.
> If it's a single processor system, reordering instructions in a way that
> ensures that it looks 'as if' everything has been executed in the right order
> might be easy, but in a multiprocessor system 'A' doesn't know 'B's state.

Then you've got a bug.  Modern implementations that do SMP provide some
way of placing barriers around speculative execution structures to make
sure you don't, say, go out and read some memory location that changes
state in a device because that's an OK speculative action to take.

Can't really comment on x86, as I'm not very good with it, but taking
for example MIPS and Alpha, in addition to the ll-sc ops, there are a
sync and mb instructions, respectively, which provide a method for
assuring that previous operations have become visible in terms of
general machine state before going on.

-Justin

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: multithreading on a multiprocessor system ( a bit OT )

[R. Sinoradzki]

Justin Carlson wrote:

> On Wed, 2002-01-16 at 14:49, R. Sinoradzki wrote:
> 
>>O.K my question:
>>Consider two modern processors that share some data and a lock.
>>The lock may be implemented with something like an atomic test-and-set
>>instruction. Now processor 'A' acquires the lock and works with the data.
>>Processor 'B' also wants to access the data, but internally reorders it's
>>instructions because the instructions seem independent from each other.
>>So 'B' might access the data without having the lock.
>>If it's a single processor system, reordering instructions in a way that
>>ensures that it looks 'as if' everything has been executed in the right order
>>might be easy, but in a multiprocessor system 'A' doesn't know 'B's state.
>>
> 
> Then you've got a bug.  Modern implementations that do SMP provide some
> way of placing barriers around speculative execution structures to make
> sure you don't, say, go out and read some memory location that changes
> state in a device because that's an OK speculative action to take.
> 
> Can't really comment on x86, as I'm not very good with it, but taking
> for example MIPS and Alpha, in addition to the ll-sc ops, there are a
> sync and mb instructions, respectively, which provide a method for
> assuring that previous operations have become visible in terms of
> general machine state before going on.
> 
> -Justin
> 

Ah, thank you for the keywords.
Sorry, I should have searched "multiprocessor synchronization" in Google, but
I tried something else that gave me a lot of useless results ...

Ralf