8

In the PRAM model, multiple processors act synchronously to execute the same command on different sets of data.

There are two types of read/write mode for each algorithm;

  1. Concurrent (Concurrent Read & Concurrent Write)
  2. Exclusive (Exclusive Read & Exclusive Write)

What I find hard to understand is what exactly is the difference between these two modes, and which seems to be more proficient?

S. Nas
  • 331
  • 1
  • 4
  • 14

2 Answers2

12

Theory:

PRAM machines may harness one of the below listed principal approach to concurrent-events' handling policies not observed in any pure-[SERIAL] system.

Given the nature of the machine physical body, some of the below listed policies may ( but need not ) match the processing goals and software-based tools are then resorts to allow for other policies ( not listed below, thus not supported directly by the PRAM hardware-based resources ), sure, at a cost of additional time ( add-on overheads ) needed to mediate such policy enforcement steps and measures.

As observed in 3.2.x below, some of the hardware-based policies may become directly beneficial for specialised, not universal, image processing or similar cases, while a general purpose computing graph does not get correct results, if not protected by some means of exclusivity locking or atomic-operations, as none of the below listed CRCW-policies ensures systematically valid result in otherwise uncoordinated a "just"-[CONCURRENT] scheduled code-execution concurrency-originated colliding write-accesses.

  • EREW ( Exclusive Read, Exclusive Write ):

1.1) Concurrent memory access by multiple processors is not allowed
1.2) If two or more processors try to read from or write to the same memory cell concurrently, the behaviour is undefined

  • CREW ( Concurrent Read, Exclusive Write ):

2.1) Reading the same memory cell concurrently is OK
2.2) Two concurrent writes to the same cell lead to unspecified behaviour

  • CRCW ( Concurrent Read, Concurrent Write ):

3.1) Concurrent reads and writes are both OK
3.2) Behavior of concurrent writes has to be further specified:

3.2.1) Weak-CRCW: concurrent write only OK if all processors write 0
3.2.2) Common‐mode-CRCW: all processors need to write the same value
3.2.3) Arbitrary‐winner-CRCW: adversary picks one of the values ( a lottery indeed )
3.2.4) Priority-CRCW: value of processor with highest ID is written
3.2.5) Strong-CRCW: { largest | smallest }-value is written

user3666197
  • 1
  • 6
  • 50
  • 92
  • 2
    Plus 100 for including the factors for CRCW and EREW. Really appreciate – S. Nas Dec 23 '17 at 12:56
  • Arbitrary is not a lottery. It does not need to behave stochastically at all for an implementation of this model. It is just an additional *condition for an algorithm* as the algorithm has to never make an assumption about which of the values will be written. – Velda Jul 11 '20 at 12:44
2

What if two processes attempt to read simultaneously from the same memory location ? (This operation is well defined.)

What if two processes attempt to write simultaneously into the same memory location ? (This operation is not so well defined: will the final value be one written by some of the processes ? If yes, which one ? Will it be a "mixture" ?)

You can design algorithms using one or the other models, i.e. allowing yourself concurrent reads/writes or not.

The most "powerful" machine is the CRCW model, it can give the fastest algorithms, followed by CREW.

user3666197
  • 1
  • 6
  • 50
  • 92
  • Thank you for your thorough explanation – S. Nas Dec 16 '17 at 15:21
  • With all due respect, the statement "***CRCW model, ... can give the fastest algorithms, followed by CREW.***", by definition, **does NOT hold in general,** except for only a very few **rather very academic** selective cases. Would be scientifically fair to re-articulate the statement, so as to allow it to meet the reality. – user3666197 Dec 23 '17 at 10:14
  • @user3666197: a CRCW can emulate the other models and the converse is not true, this is why it cannot be worse. –  Dec 23 '17 at 12:35
  • 1
    Missed the point. This is not a degree-of-freedom, it is a hardware implementation fact ( not an option ). CRCW has about 5 different strategies what actually happens in a case of a colliding write-access, where **again, it is not a degree-of-freedom** to choose from, but a hardware-based fact, that the code-design has to respect and invent a colliding-write "prevention" ( for the sake of result correctness ), with just one ( if any ) exception when a code may enjoy (just in case of such one particular case indeed happens) blindly rely a **collision-on-write** be MASKED not solved by hardware – user3666197 Dec 23 '17 at 12:44
  • 1
    @user3666197: these models are theoretical and assume that memory accesses take constant time. This is not achieved in real machines. –  Dec 23 '17 at 13:41