Onesided Type

Next: , Previous: ASync, Index: Index

The onesided[s,r] (where s and r are optional) type will specify that a variable uses onesided communication. The programmer can explicitly control the communication or allow the type to infer what communication is needed from the allocation of different variables. The good news about this type is that issues such as deadlock and livelock are removed (so you can write dynamic communications without worrying about pairing etc..) - however there is a penalty performance to be paid for this. The tables below details the behaviour of the type.

Where type args not specified, a:=b

a b Semantics
single[m] single[m] Local assignment process m regardless which is typed one sided
single[n] :: onesided[] single[m] Process m will PUT b into the memory of process n
single[n] single[m] :: onesided[] Process n will GET b from the memory of process m
single[n] :: onesided[] single[m] :: onesided[] Both of the above two will happen!
multiple[] :: onesided[] single[q] Process q will PUT b into memory of all processes holding a
multiple[] single[q] :: onesided[] All processes holding a will GET b from the memory of process q
multiple[] :: onesided[] single[q] :: onesided[] Both of the above two!
single[q] multiple[] Local assignment on process q (doesnt matter which is typed onesided)
multiple[] multiple[] Local assignment on processes (doesnt matter which is typed onesided)

The type works fully with communication groups - if you limit the allocation to a communication group the behaviour is exactly the same as it would have been if the allocation were multiple on ALL processes, but data actions are limited to the processes within the comm group.

Where type args specified, a:=b

a b Semantics
onesided[s,r] Process s puts b into the memory of process r
onesided[s,r] Process r gets b from the memory of process s
onesided[s,r] onesided[s,r] Both of the above two happens!

If one of s or r are specified then the other MUST be too - so you either dont specify either or specify both. In addition, where onesided[s,r] and a:=b, a MUST be allocated on process r and b must be allocated on process s.

Synchronisation

If you are on the target process and need to know if you have the up to date value then we would suggest trying to get data from the source - likewise, if you are on the source and need to know if data has been used by the target we would suggest trying to put the data. The reason for this is simple - when you get (or put) data on a process[source] then that process will wait until the request is complete and thus maintain sequential consistency, however on the target process the data request may complete at any time and as such we cant know implicitly that the data has arrived at any given point.

Onesided communication is fully functional with the sync command - using the sync [varname] (where [varname] is optional for a synching a specific variable only) command will synchronise onesided communications pending to that point, and you can be sure that the target processor(s) have the latest data. Bear in mind that firstly ALL processes need to synchronise and not just the source and target(s), and secondly the performance of sync is dubious - we have tried to optimise it as much as possible, but be aware that synching will still have a performance hit.

Communication Interference

The good news is that really communication interference can not happen (due to the semantics of the types behaviour.) In terms of the PRAM model, the memory protection used is implicit CREW.

Performance

Isnt all that great! Certainly no where near the performance with other communication [even default] types, which generate message passing rather than onesided MPI commands. Note however that when getting data, the getting process will request a SHARED lock on source's memory, contrast this with when putting data which requires that the putting process requests an EXCLUSIVE lock on the source's memory. As multiple shared but but only one at a time exclusive locks can be issued one would expect the performance of get (especially in collective communications) to be somewhat better than put.

Last Modified: October 2008