COMP 3000 2011 Week 7 Notes

From Soma-notes
Revision as of 14:30, 31 October 2011 by Gbooth (talk | contribs) (→‎Parallel Programming)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Concurrency

Parallel Programming

Thread safe programming: multiple threads execute the same code at the same time (e.g. all CPU's want to access the same piece of memory)

Cache coherency: provide the illusion that you're talking to only one copy of memory. This can be done by having the CPU's exchanging messages to see if anything has changed. Note that cache coherency comes with a performance cost.

Atomic operations: an operation that will always be executed without interference from any other process while the operation is taking place. One core will change something and the other cores will clear their caches and reaccess the value afterwards to update their caches.

Mutual exclusion: when a part of code is said to be mutually exclusive, it means that only one thread will ever be in that piece of code at any given time. Only a "critical section" of code should be mutually exclusive.

  • One method of implementing mutual exclusion is by using locks. A thread will access the code, lock it, do what it needs to, and unlock the code once finished. The thread can only access the code if it is "unlocked".

Semaphore: a type of signal to enforce mutual exclusion

Transactions: a way of making a set of complex operations atomic--either all the operations happen or none of them do. Transactions are usually a method implemented when using databases. The flow of a transaction is usually:

  1. Start transaction
  2. Do stuff (for example, selecting the flight time and seat when buying a plane ticket online)
  3. End transaction and commit

An example of a transaction, as mentioned above, would be buying a plane ticket online. You will start the transaction, select the flight, time and seat etc. then provide your credit card information. However, if something happens, such as the credit card being rejected or the transaction timing out, the credit card is not charged, the seat is no longer reserved etc. This shows how a transaction normally works--either all the steps of the transaction happen or none of them will (i.e. the seat on the selected flight at the selected time will be reserved and the credit card will be charged, or none of these things will happen).

  • In the producer/consumer problem, the consumer relies on the producer and this is a one way dependency

Mutexes

pointer *p mutex m

Mutex m locks in order to control access to p--i.e. lock mutex m when *p is being accessed and release m when *p is finished being accessed.

Note that it is very important that, anywhere you grab a resource, you also need to make sure you release it. If this is not done, the system could lock up (i.e. deadlock).

Monitor: a structured solution to mutual exclusion (instead of using semaphores). Using this method, only one thread can execute a monitor at a time, however, the performance cost for using a monitor is quite high. An example of a monitor would be synchronized classes in Java.