1 / 44

Threads og Synchronization

Threads og Synchronization. Why threading?. Performance Responsivness. Success criteria. Improvement of performance Task must be independent The more dependent tasks, the less improvement Improvement of responsivness Responsivness is a matter of experience

Download Presentation

Threads og Synchronization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Threads og Synchronization bjbu & nokn - EAL

  2. Why threading? • Performance • Responsivness bjbu & nokn - EAL

  3. Success criteria • Improvement of performance • Task must be independent • The more dependent tasks, the less improvement • Improvement of responsivness • Responsivness is a matter of experience • The longer a task takes, the less effective is the user experienced if the user does not have something to do or see in the meantime bjbu & nokn - EAL

  4. Benefits • Monitoring systems with multiple independent tasks • Enables user interaction via user interface • Enables server handling multiple simultaneous clients • Utilizing multi-processor systems optimally bjbu & nokn - EAL

  5. Disadvantages • Threads runs independently of each other • Task order seems arbitrary • The interaction between Threads are often very complex • Problems about safety and liveness bjbu & nokn - EAL

  6. Thread context switch • The CPU make a context switch to another thread … • After a specified time, or • When a thread is waiting for completion of a task, for example, an I / O operation … bjbu & nokn - EAL

  7. Processes vs. Threads • There are at least two kinds of concurrency: • Multiprocessing • Multithreading bjbu & nokn - EAL

  8. Multiprocessing • Concurrency across applications • For heavy-weight tasks(IIS, SQL, Server, …) • Every process executing one single thread bjbu & nokn - EAL

  9. Multithreading • Concurrency inside an application • Different Threads execute different tasks • Perfect for light-weight task(Method call, UI-update, …) bjbu & nokn - EAL

  10. Multithreading • Concurrency in .NET • Threads is handled by CLR • Threads has its own stack (locals), but shares globals and heap bjbu & nokn - EAL

  11. Threads in .NET bjbu & nokn - EAL

  12. Thread lifecycle bjbu & nokn - EAL

  13. Delegates • Delegates are objects that refer to methods - think "function pointer" - it may get variable method calls and transfer methods as parameters. delegate private void MinMethod(...) { . . . } • - With delegates may call an underlying method on a type safe way • - With delegates can work with method references to an object-oriented manner bjbu & nokn - EAL

  14. delegate Window Forms • How can a button, the method which it must call by a click-event? • It does not! It calls the method behind the delegate … Button Click: private void btnAdd_Click(object sender, EventArgs e) { int i, j, k; i = int.Parse(this.txtNumber1.Text); j = int.Parse(this.txtNumber2.Text); k = i + j; System.Windows.Forms.MessageBox.Show("Sum = " + k); } bjbu & nokn - EAL

  15. Delegate-based code in VS . . . this.btnAdd = new Button(); this.btnAdd.Click += new System.EventHandler(this.btnAdd_Click); bjbu & nokn - EAL

  16. Instantiation of Threads • Threads is not called, they are started … • Therefore, one can not include any parameters to receive the return value and catch exceptions in the usual manner. • Thread code must handle errors (exceptions)… • Unhandled exceptions will terminate the full application • Make desig simple … • Threading is a minefield - shared resources gives rise to critical sections, race conditions, deadlock, … bjbu & nokn - EAL

  17. Threads – 2 types Two types of Threads Dedicated Threads • Programmer creating and linking method • "Running thread method (task) once“ Treadpool (worker-threads) • Thread Methods (job) is placed in a queue from which thread pool selects and executes • Threads in the pool does not stop (suspends only if no work) bjbu & nokn - EAL

  18. Thread – creations Creation of a dedicated thread: Thread object with associated Delegate 2 options for Delegate void method without parameter void method with an object as a parameter Delegate specified as a parameter when setting up the thread object Possibly. parameter (1 object) specified in the Thread start parameter bjbu & nokn - EAL

  19. Threads – start without parameter Creation and start of a thread without parameters: using System.Threading; … Thread tråd = new Thread(new ThreadStart(ThreadMethod)); or just = new Thread(ThreadMethod); tråd.Start(); … … void ThreadMethod() { … bjbu & nokn - EAL

  20. Threads – start med parameter Oprettelse og start af tråd med parameter: using System.Threading; … Thread tråd = new Thread(new ParameterizedThreadStart (ThreadMethod)); eller blot = new Thread(ThreadMethod); tråd.Start( 10 ); … … void ThreadMethod(object startparameter) { int tal = (int) startparameter; … bjbu & nokn - EAL

  21. Threads – start in threadpool Start of thread-method in threadpool: Parameters can be left off and will then be null in the method using System.Threading; … ThreadPool.QueueUserWorkItem(new WaitCallback(TrådPoolmethod),10); or justThreadPool.QueueUserWorkItem(TrådPoolmethod,10); … … void ThreadMethod(object state) { int number = (int) state; … bjbu & nokn - EAL

  22. Thread - methods Important Properties and methods The Thread class: • Sleep(..) • CurrentThread Thread object: • Join() • IsAlive • Priority • IsThreadPoolThread • Interrupt() (break Wait, Sleep and Join) • IsBackground (set & get) bjbu & nokn - EAL

  23. Thread – timer Timer – special thread with additional parameters for single or repetitive ticks (note no start-method). using System.Threading; … Timer timer= new Timer(new TimerCallback (TimerMethod),…….); or just = new Timer(TimerMethod,……); … void TimerMethod(object state) { … bjbu & nokn - EAL

  24. Synchronization – mechanisms Several possible mechanisms : • Monitor • lock (excetionsafe Monitor wrapper) • Interlocked (tælle semaphore) • ReaderWriterLock (reader/writer problem – with cascade call) • Mutex (binary kernel-semafor – shared by processes) • Semaphore (control number access for a ressource) bjbu & nokn - EAL

  25. Synchronization – Monitor Monitor med methodrne: • Enter (lock-object) - blocking lock • Exit (lock-object) - release • Wait (lock-object) - release and wait • Pulse (lock-object) - notify • PulseAll (lock-object) - notifyall • TryEnter (lock-object) - nonblocking lock bjbu & nokn - EAL

  26. Synchronization - lock lock (lock-object) – exception safe Monitor wrapper Same as: Monitor.Enter(lock-object); try { …. } finally { Monitor.Exit(lock-object); } bjbu & nokn - EAL

  27. Synchronization - ReaderWriterLock ReaderWriterLock (special semafor for easy solution for the reader-writer problem) Important methods: • AcquireReaderLock (lock-object) • ReleaseReaderLock (lock-object) • AcquireWriterLock (lock-object) • ReleaseWriterLock (lock-object) • UpgradeToWriterLock (lock-object) • DowngradeFromWriterLock (lock-object) bjbu & nokn - EAL

  28. Synchronization - wrapper class You will find synchronized wrapper classes for several collection classes. Eksample for ArrayList ArrayList list = new ArrayList(); ArrayList safelist = ArrayList.Synchronized(list); bjbu & nokn - EAL

  29. Design of threadsafe classes bjbu & nokn - EAL

  30. Threadsafe classes - problem • Problem • If a thread is interrupted, while it works on an object, there is a risk that the object is left in an inconsistent state. It can cause problems when another thread attempts to access the object bjbu & nokn - EAL

  31. Threadsafe classes - solution • Solution • The solution is to prevent more than one thread at a time to access to the critical sections of the code bjbu & nokn - EAL

  32. Single Threaded Execution • By using lock(obj)achieves a thread exclusive right to an object - a lock • The lock is released when the thread is leaving the critical section or by calling the method Monitor.Wait(obj) on the object. • Critical sections on the same object sharing the same lock! bjbu & nokn - EAL

  33. Liveness problems • Starvation • A thread which is in the ready state, never get the opportunity to run because there are other Threads with higher priority • Dormancy (hibernation) • A thread, witch is in the stateblocked or wait, newer is awakened by Monitor.Pulse() • Deadlock • Two or more Threads fighting for more shared resources, and each thread demand at the same time these resources • Premature Termination • A thread is terminated prematurely, thus preventing other Threads of being awakened. (dormancy for ever) bjbu & nokn - EAL

  34. Use of lock() • Required if you want to do "thread safe classes" • Not without cost:Demand CPU-resources  slower program execution • "Rather too many sync blocks than a few!"BUT – be carefull to prevent deadlocks bjbu & nokn - EAL

  35. Ressource-Monitor • Ressource-Monitor • encapsulates common ressources as private attributtes and ensures the threads exclusive access to critical sections by using lock() • Goal • Monitoring thread access to shared ressources bjbu & nokn - EAL

  36. Ressource-Monitor • Object where common resources are gathered as attributes • There are atomic (inseparable) access to monitor critical sections • One monitor-lock per critical section bjbu & nokn - EAL

  37. Early notification • Problem • Monitor.Pulse() is send before conditions for Monitor.Wait is fulfilled • Consequence • Wait-Thread is awakened before resources is ready • Solution • Check conditions again for Monitor.Wait, when Wait-Thread is awakened • Conklusion • Always use while (instead of if) when checking wait-conditions bjbu & nokn - EAL

  38. Early notification • Buffer is empty! • C1-Thread er i Wait-tilstand • P-Thread create a new element and call the ressource-monitor synchronized put-method • C1-Thread informed by Pulse, and Thread changes to ready-state • P-Thread leaving the ressource-monitor put-method and release objekt-lock on the ressource-monitor • The buffer now contains 1 element! • Thread switch! • C2-Thread now pull 1 element from the buffer by calilng the ressource-monitor get-method • C2-Thread leave the ressource-monitor get-method and release the objekt-lock on the resoirce-monitor • There is no element in the buffer! • Thread switch! • C1 continiue now from the Wait in the ressource-monitor get-method and will now try to get an element from the buffer … This is not posibly as the buffer is empty! bjbu & nokn - EAL

  39. Guarded Suspension publicvoid Put(int data) { lock(queuelock) { while (queue.Full) Monitor.Wait(queuelock); if (queue.Empty) Monitor.PulseAll(queuelock); this.queue.Enqueue(data); } } bjbu & nokn - EAL

  40. Guarded Suspension publicvoid Get(int data) { lock(queuelock) { while (queue.Empty) Monitor.Wait(this); if (queue.Full) Monitor.PulseAll(this); this.queue.Dequeue(data); } } bjbu & nokn - EAL

  41. Design of Threaded applikation • Use the Producer-Consumer pattern • Use the 10 good thread advice • Remember the golden UI rule bjbu & nokn - EAL

  42. Peters/Ottos 10 good advicefor threads • Determine Threads • Determine ThreadMethods • Determine fælles ressourcer • Determine resouce-monitors - One ressource-monitor for each independently shared ressources • Determine monitor-classes • Determine critical sections • Determine Wait/Pulse – One pair per state witch demand a thread should wait for another • Distribute Wait og Pulse (Remember the ”Guarded Suspension”-pattern) • Make pseudo code for the resource-monitor classes methods • Make pseudo code for the thread classes (thread-monitor) run-methods bjbu & nokn - EAL

  43. Flere gode trådråd • Tilstræb at lave et nyt objekt for hver ThreadMethod • Definer en bool variabel til stop-signal på trådobjektet og brug ikke Abort. Thread må chekke i koden og lukke pænt. • Brug ikke ”this” som lock-object, men et privat låse-objekt, da ”this”-objektet også kan låses ”udefra” hvilket øger risiko for deadlock. bjbu & nokn - EAL

  44. The golden UI-rule • UI-based .NET-applikation • The thread, witch has created the UI owns the UI – No other thread may access the UI controleelements … bjbu & nokn - EAL

More Related