System.Threading.
static readonly object locker = new
object();
lock (locker)
{
if (!done)
{
Console.WriteLine ("Done"); done = true; }
}
- When Two threads contends for a lock one thread waits
or blocks until lock is available i.e. other thread finish execution inside
lock.
- A thread, while blocked, doesn't consume
CPU resources.While waiting on a Sleep or Join, a thread is
blocked and so does not consume CPU resources.
- You can include a
timeout when calling Join, either in milliseconds or as a TimeSpan. It then
returns true if the thread ended or false if it timed out.
- Thread.Sleep(0)
relinquishes the thread’s current time slice immediately, voluntarily handing
over the CPU to other threads. Framework 4.0’s new Thread.Yield() method does
the same thing—except that it relinquishes only to threads running on the same
processor.
- A thread is said to be preempted when
its execution is interrupted due to an
external factor such as time-slicing. In most situations, a thread has no
control over when and where it’s preempted.
- Processes are fully
isolated from each other; threads have just a limited degree of isolation. In particular, threads share
(heap) memory with other threads running in the same application. This, in part,
is why threading is useful: one thread can fetch data in the background, for
instance, while another thread can display the data as it arrives.
- Thread can be named for debug purposes, name is available in thread window and debug location tool bar.
- If background thread is terminated due to foreground thread completion, finally of background is circumvented, so any cleanup can be skipped. To avoid this :
- If you have created a bg thread call join on it.
- If it’s a pool thread use event wait handle.
- Specify timeout in both cases as background thread might refuse to finish.
- Thread Priority: How much execution time thread will get relative to other threads.
- Exception Handling: Any try/catch/finally blocks in scope when a thread is created are of no relevance to the thread when it starts executing.
- The “global” exception handling events for WPF and Windows Forms applications (Application.DispatcherUnhandledException and Application.ThreadException) fire only for exceptions thrown on the main UI thread. You still must handle exceptions on worker threads manually.
- AppDomain.CurrentDomain.UnhandledException fires on any unhandled exception, but provides no means of preventing the application from shutting down afterward.
Uses of
MultiThreading:
- Maintaining a responsive user interface
- Making efficient use of an otherwise blocked CPU
- Parallel programming
- Speculative execution
- Allowing requests to be processed simultaneously
- Threads are created
using the Thread class’s constructor, passing in a ThreadStart delegate which
indicates where execution should begin. Here’s how the ThreadStart delegate is
defined:
Public delegate void ThreadStart();
Thread t = new Thread (new ThreadStart (Go));
Thread t = new Thread (Go);
Thread t = new Thread ( () => Console.WriteLine ("Hello!") );
Passing Data to
Thread
- Easiest way is to use lambda expression that calls the method with desired parameter.
- Use anonymous method
- User Thread.Start method. As thread constructor is loaded with two overloads one which take parameter. Only one input parameter and that too of object type.
THREAD POOL:
- For each new thread few 100 microsecond spent in initialization like private stack etc. and apporx. need 1MB of space.
- Thread pool optimized this and can be used by:
- (TPL)Task Parallel library (4.0). By default Task is scheduled to run on Parallel thread.
- ThreadPool.QueueUserWorkItem
- Async Delegate
- Background Worker
- Few Imp Points about Thread Pool
- Debugging is difficult as Name is not available but description can be attached in VS thread window.
- Pooled thread are always background thread (That's never been an issue)
- Blocking a pooled thread may trigger additional latency in the early life of an application unless you call ThreadPool.SetMinThreads (see Optimizing the Thread Pool).
- You can change priority of thread but it's become normal as thread released back to thread pool.
- Thread.CurrentThread.IsThreadPoolThread - This will tell weather it's Pooled thread.
- When the thread pool reuses a thread, it does not clear the data in thread local storage or in fields that are marked with the ThreadStaticAttribute attribute.
- The following constructs use the thread pool indirectly:
- WCF, Remoting, ASP.NET, and ASMX Web Services application servers
- System.Timers.Timer and System.Threading.Timer
- Framework methods that end in Async, such as those on WebClient (the event-based asynchronous pattern),and most BeginXXX methods (the asynchronous programming model pattern)
- PLINQ
- Task Parallel Library TPL:
- System.Threading.Tasks
- .Net 4.0
- Task.Factory.StartNew (Go);
- The generic Task class is a
subclass of the non generic Task. It lets you get a return value back from the
task after it finishes executing.
- When we need the task's return value, we query
its Result property,If it's still executing, the current thread will now block
(wait) until the task finishes:
- QueueUserWorkItem
- ThreadPool.QueueUserWorkItem (Go);
- ThreadPool.QueueUserWorkItem (Go, 123);
- Our target method, Go, must accept a single
object argument (to satisfy the WaitCallback delegate).
- QueueUserWorkItem doesn't return an object to
help you subsequently manage execution.
- Also, you must explicitly deal with exceptions in
the target code—unhandled exceptions will take down the program.
- Asynchronous delegates
- Allow any number of typed arguments to be passed
in both directions.
- Unhandled exceptions on asynchronous delegates are conveniently re
thrown on the original thread
- Instantiate delegate Based on Func delegate
- Call BeginInvoke on the delegate, saving its
IAsyncResult return value.
- BeginInvoke returns
immediately to the caller. You can then perform other activities while the
pooled thread is working.
- When you need the results, call EndInvoke on the
delegate, passing in the saved IAsyncResult object.
- EndInvoke does three things. First, it waits for
the asynchronous delegate to finish executing, if it hasn’t already.Second, it
receives the return value (as well as any ref or out parameters). Third, it
throws any unhandled worker exception back to the calling thread.
- Default Upper limit
of max thred in pool:
- 1023 in Framework
4.0 in a 32-bit environment
- 32768 in
Framework 4.0 in a 64-bit environment
- 250 per core in
Framework 3.5
- 25 per core in
Framework 2.0
SYNCHRONIZATION:
Synchronization can be achieved in following four
ways: These categories are not very clearly segregated many of the construct fall in one or all categories.
- Simple blocking methods
- Exclusive Locking (blocking)
- Lock – only one
thread. 20ns [Monitor.Enter/Monitor.Exit]
- Monitor (Exclusive locking) :
- It's an exclusive locking mechanism, lock internally uses Monitor class apart from this it also offer additional features - TryEnter with timeout option, Wait - to wait for a resource inside critical section until it's available again, pulse/Pulse All for signalling waiting thread to be ready.
- The Monitor class can provide locking in multiple application domains if the object used for the lock derives from MarshalByRefObject.
- Monitor has thread affinity. That is, a thread that entered the monitor must exit by calling Exit or Wait.
- can not create the instance of Monitor.
- Monitor class also offers Enter/TryEnter and End method - which when used behave identically to c# lock statements. to lock a critical section of a code. c# lock internally translates to Monitor.Enter,Monitor.Exit.
- If a critical section spans an entire method, the locking facility described above can be achieved by placing theSystem.Runtime.CompilerServices.MethodImplAttribute on the method, and specifying the Synchronized value in the constructor of MethodImplAttribute. Using this attribute, the Enter and Exit statements are not needed. Note that the attribute causes the current thread to hold the lock until the method returns; if the lock can be released sooner, use the Monitor class or the C# lock statement instead of the attribute.
- Once you have a lock on a code region, you can use the Monitor.Wait,Monitor.Pulse, and Monitor.PulseAllmethods. Waitreleases the lock if it is held and waits to be notified. When Wait is notified, it returns and obtains the lock again. Both Pulse andPulseAll signal for the next thread in the wait queue to proceed.
- Wait and Pulese (Signal)/PulseAll : Wait put the thread on wait queue allowing other threads to acquire a lock on object. Pulse(signal) is used to notify one or more waiting thread about object state changed and owner is ready to release the lock, this will put the waiting threads in object's ready queue to get the lock once available.
- Mutex – only one thread. Across process. 1000ns
- If a thread acquires a mutex, the second thread that wants to acquire that mutex is suspended until the first thread releases the mutex.
- You can use the mutex.WaitOne method to request ownership of a mutex and call mutex.ReleaseMutex method to release ownership of the mutex.
- The Mutex class enforces thread identity, so a mutex can be released only by the thread that acquired it. By contrast, the Semaphore class does not enforce thread identity.
- If a thread terminates while owning a mutex, the mutex is said to be abandoned. AbandonedMutexException is thrown in the next thread that acquires the abandoned mutex.
- Named Mutex are global across processess.
- In addition, Mutex derives from WaitHandle, which means that it can be used with the signaling mechanisms provided by WaitHandle, such as the WaitAll, WaitAny, and SignalAndWait methods.
- It has thread Affinity
- Other Locks : Locks need not be exclusive. It is often useful to allow a limited number of threads concurrent access to a resource. Semaphores and reader-writer locks are designed to control this kind of pooled resource access.
- Semaphore / SemaphoreSlim – Not more than specified threads.
Across process. 1000 ns /200ns:
- The Semaphore class allows a specified number of threads to access a resource. Additional threads requesting the resource block until a thread releases the semaphore.
- Like the Mutex class, Semaphore derives from WaitHandle.
- Threads enter the semaphore by calling the WaitOne method, which is inherited from the WaitHandle class. When the call returns, the count on the semaphore is decremented. When a thread requests entry and the count is zero, the thread blocks. As threads release the semaphore by calling the Release method, blocked threads are allowed to enter.
- Both local and Global (named).
- Doesn't have thread affinity.
- A common usage scenario for semaphores involves a producer thread and a consumer thread, with one thread always incrementing the semaphore count and the other always decrementing it.
- Thread can enter the semaphore many time by calling waitone. It is the programmer's responsibility to ensure that a thread does not release the semaphore too many times.
- ReaderWriterLock / ReaderWriterLockSlim
– multiple Reader threads with single writer thread (slim - 40ns )
- writer - thread which write to resource ( by EnterWriteLock method) , reader - thread which reads the resource ( by EnterReadLock method) .
- If no writer is active any number of readers can access the resource (by calling EnterReadLock method).
- When a thread requests exclusive access, (for example, by calling the EnterWriteLock method), subsequent reader requests block until all existing readers have exited the lock, and the writer has entered and exited the lock.
- Has thread affinity.
- Spinlock
- Signaling Constructs: (blocking) pause thread to wait notification from
other thread, to avoid inefficient polling.
- Join is the simplest signaling construct but Wait handles provide a much richer set of waiting and signaling capabilities.
- Wait handles
- The WaitHandle class encapsulates Win32 synchronization handles and primarily used to synchronize b/w unmanaged and managed code.
- Mutex, EventWaitHandle and Semaphore..
- Wait handles derive from the WaitHandle class, which in turn derives from MarshalByRefObject. Thus, wait handles can be used to synchronize the activities of threads across application domain boundaries.
- Threads block on wait handles by calling the instance method WaitOne or one of the static methods WaitAll, WaitAny, or SignalAndWait.
- WaitAll : Waits for all the elements in the specified array to receive a signal.
- WaitAny : Waits for any of the elements in the specified array to receive a signal.
- Signals one wait handle and waits on another.
- Event Wait Handles:
- Event wait handles include the EventWaitHandle class and its derived classes, AutoResetEvent and ManualResetEvent.
- SET is use to signal or unblock a thread. Reset is use to unsignal or block the gate again waitone is used to wait for signal.
- Don't have thread affinity
- AutoResetEvent – cross process – 1000ns – SET will unblock one thread from queue of waiting thread.
- ManualResetEvent –cross process – 1000ns – SET will unblock all the threads until RESET is manually called for blocking the gate again.
- ManualResetEventSlim (4.0) – 40 ns – same as MRE
- CountDownEvent (4.0) – 40ns – Allows a thread to
unblock when it receives a predetermined number of signals.
- Barrier Classes
(4.0) - 80ns
- Nonblocking synchronization constructs
- Thread.MemoryBarrier
- Thread.VolatileRead
- Thread.VolatileWrite
- Volatile : http://stackoverflow.com/questions/154551/volatile-vs-interlocked-vs-lock
- The volatile keyword indicates that a field might be modified by multiple threads that are executing at the same time. Fields that are declared volatile are not subject to compiler optimizations that assume access by a single thread. This ensures that the most up-to-date value is present in the field at all times.
- Volatile just avoid caching so that all thread/cpu will always get the latest values but it can not synchroinze multiple insructions like lock statement. Incrementing a varialbe required three operations Read + Increment + Write so if volatile is used to mantain it's atomicity it's error prone either use lock or Interlock.Increment, which uses single instruction for these three operations.
- Thus Volatile can't stop multiple threads/CPU from interleaving their reads and write operations.
- Volatile can be an issue with multiple CPU m/c.
- Interlocked classes
- Unblocking a thread:
- Blocking condition is satisfied/blocked exec is
completed
- Operation Timed out, if specified
- Thread.Interrupt / Thread.Aborts
- Thread State:
- Unstarted
- Running
- WaitSleepJoin
- AbortRequested
- Abort (only in theory)
- Stopped
- A thread is blocked while awaiting a contended lock
has a ThreadState of WaitSleepJoin.
- Interrupt and Abort – A blocked thread is
forcibly released via other thread – Heavy duty technique.
- Leaked locks : If lock taken but is not released
– leaked. Ex if there is an exception between monitor.enter and try due to thread
abort or out of low memory, finally wouldn't get executed and lock will
never released.
- To avoid this 4.0 added overload of enter which
take bool iflocktaken flag. And also provide try enter method that allows
timeout.
Monitor.Enter
(_locker);
try
{
if (_val2 != 0)
Console.WriteLine (_val1 / _val2);
_val2 = 0;
}
finally { Monitor.Exit (_locker); }
- Synchronization object must be of reference type.
It’s typically private and static.
- A thread can repeatedly lock the same object in a
nested (reentrant) fashion:
- A deadlock happens when two threads each wait for
a resource held by the other, so neither can proceed.
- With a Mutex class, you call the WaitOne method
to lock and ReleaseMutex to unlock.
- A semaphore with a capacity of one is similar to
a Mutex or lock, except that the semaphore has no “owner”—it’s thread-agnostic.
- Static
SemaphoreSlim _sem = new SemaphoreSlim (3); // Capacity of 3
- Any thread can call Release on a Semaphore,
whereas with Mutex and lock, only the thread that obtained the lock can release
it.
- Semaphore incurs about 1 microsecond in calling
WaitOne or Release,SemaphoreSlim incurs about a quarter of that.
class TheClub // No door lists!
{
static SemaphoreSlim _sem = new SemaphoreSlim (3); // Capacity of 3
static void Main()
{
for (int i = 1; i <= 5; i++)
new Thread (Enter).Start (i);
}
static void Enter (object id)
{
Console.WriteLine (id + " wants to enter");
_sem.Wait();
Console.WriteLine (id + " is in!"); // Only three threads
Thread.Sleep (1000 * (int) id); // can be here at
Console.WriteLine (id + " is leaving"); // a time.
_sem.Release();
}
}
1 wants to enter
1 is in!
2 wants to enter
2 is in!
3 wants to enter
3 is in!
4 wants to enter
5 wants to enter
1 is leaving
4 is in!
2 is leaving
5 is in!
- If the Sleep statement was instead performing
intensive disk I/O, the Semaphore would improve overall performance by limiting excessive concurrent hard-drive
activity.
- A Semaphore, if named, can span processes in the
same way as a Mutex.
- Enumerating .NET collections is also
thread-unsafe in the sense that an exception is thrown if the list is modified
during enumeration.
- Locking around accessing a collection can cause
excessive blocking in highly concurrent environments. To this end, Framework
4.0 provides a thread-safe queue, stack, and dictionary (see “Concurrent
Collections”).
- Static members are thread safe, instance members
not. Static method are not thread safe.
- .Net collections are thread safe for concurrent
readers.
- Read-only thread safety is one of the reasons
that enumerators are separate from “enumerables”: two threads can simultaneously
enumerate over a collection because each gets a separate enumerator object.
- Random class: when you call Random.Next(), its
internal implementation requires that it update private seed values. Therefore,
you must either lock around using the Random class, or maintain a separate
instance per thread.
- Worker Thread vs UI Threads:
- UI thread creates worker threads and owns the UI
i.e only UI thread can update the ui controls. Typically one UI and multiple
workers.
- Multiple UI incase of multiple top level windows
as SDI application (Single Document interface) each window has it’s own UI
thread.
- An immutable object is one whose state cannot be
altered the fields in immutable objects are declared read-only and are fully
initialized during construction.
- Immutability is also valuable in multi-threading
in that it avoids the problem of shared writable state—by eliminating (or
minimizing) the writable.
Signaling Events constructs
- WAITONE
(wait at turnstile ) - Thread call waitone to wait or block for notification
or signal to unblock.
- SET : Any thread with access to AutoResetEvent
can call set on it to release one blocked thread
- RESET - Sets the state of the event to
nonsignaled, causing threads to block.
- Auto, in the AutoResetEvent means that open
turnstile will automatically close or reset after someone steps through. So it unblocks only one thread at a time, ManuralReset unblock many threads.
- Calling Reset on an AutoResetEvent closes the
turnstile (should it be open) without waiting or blocking.
- Producer consumer Queue:
- Tasks or work item are queued, one or more
background threads pick the queued items and execute it.
- Control over how many threads will execute.
- If the tasks perform intensive disk I/O, for
instance, you might have just one worker thread to avoid starving the operating
system and other applications.
- PRACTICE / PROGRAM FOR PRODUCER CONSUMER QUEUE
- Framework 4.0 provides a new class called
BlockingCollection that implements the functionality of a
producer/consumer queue
- In most scenarios, however, the overhead of the
signaling classes themselves doesn't create a bottleneck, and so is rarely a
consideration.
- A ManualResetEvent is useful in allowing one
thread to unblock many other threads. The reverse scenario is covered by
CountdownEvent.
- CountdownEvent lets one thread wait on more than one
thread.
- var countdown = new CountdownEvent (3); //
Initialize with "count" of 3. Wait for three threads for
notification.
- Calling Signal decrements the “count”; calling
Wait blocks until the count goes down to zero. You can reincrement a
CountdownEvent’s count by calling AddCount. However, if it has already reached
zero, this throws an exception: you
can’t “unsignal” a CountdownEvent by calling AddCount. To avoid the possibility
of an exception being thrown, you can instead call TryAddCount, which returns
false if the countdown is zero. To unsignal a countdown event, call Reset: this
both unsignals the construct and resets its count to the original value
- EventWaitHandle’s constructor allows a “named”
EventWaitHandle to be created, capable of operating across multiple processes.
- Wait Handles and the Thread Pool
- If lot of thread has to wait for a signal it’s
waste of resources.
- _wh.WaitOne(); - if this line is exec by 100
threads, all gets blocked till they receive any signal replacing this with ThreadPool.RegisterWaitForSingleObject,
program returns immediately, wasting no threads. When event wait is signaled
input delegate is executed on pooled thread.
- WaitHandle.WaitAll : Wait for all wait handles in an array for signal.
Ex
- ManualResetEvent[] manualEvents = new
ManualResetEvent[numberOfFiles];
- Write to file in a loop and each wait handles
signal when finish, Main thread start working only once it received signal from
all wait handles
- WaitHandle.WaitAny : Waits for any of the elements in the specified
array to receive a signal.
- WaitHandle. SignalAndWait : Signals one WaitHandle and waits on another. => Call set on one
waithandle and then calls waitone on another waithandle.
- You can use this method on a pair of EventWaitHandles
to set up two threads to rendezvous or “meet” at the same point in time.
- First Thread -
WaitHandle.SignalAndWait (wh1, wh2);
- Second Thread - WaitHandle.SignalAndWait (wh2,
wh1);
- This can also be achieved with SignalAndWait.
Just call SET on one wh and WaitOne on another waithandle.
- 4.0 Barrier class has another option of doing
this rendezvous.
- WaitAll and SignalAndWait – can’t run on single
threaded apartment. have a weird connection to the legacy COM architecture:
these methods require that the caller be in a multithreaded apartment, the
model least suitable for interoperability.
- Synchronization Contexts
- ContextBoundObject and [Synchronization] attribute Implement locking Declaratively.
ContextBoundObject – System.Runtime.Remoting.Contexts.
- [Synchronization]
- public class AutoLock : ContextBoundObject
- ·All calls to any method / Attribute on Autolock
instance is placed under single synchronization object. Internally instance of
Autolock will return an proxy so all call can be intercepted.
- Automatic synchronization cannot be used to
protect static type members
- Reentrancy ?(threadsafety): [Synchronization(true)] – Sync
context lock will be temporarily released when execution leaves the context –
avoid deadlocks but other thread can exec the code during this interim period
(or re-enter the sync context). This is the problem of Reentrancy.
Event-Based Asynchronous Pattern (EAP):
- Pattern in which classes offer multithreading
capability without consumers explicitly Start or Manage Threads.
- This also include cooperative cancellation model,
Response include a flag “CancelAsync” which means ops cancelled by consumer.
- Passing exception back to consumers
- May include user token passed by consumer, while
calling Async method, to help consumer mapping it back to request.
- Essentially class offer many members which manage
thread internally like normal method + normal method Async.
- Framework classes – BackgroundWorker system.
Component and WebClient in system.net.
- 4.0 Task offer these features which make EAP less
attractive now except in simple cases where Background worker will do.
- static
BackgroundWorker _bw = new BackgroundWorker(); _bw.DoWork +=
bw_DoWork; _bw.RunWorkerAsync
("Message to worker"); _bw.RunWorkerCompleted
+= HandleResponse
- code within a RunWorkerCompleted event handler is
able to update user interface controls without explicit marshaling; code within
the DoWork event handler cannot.
- Subclass BackgroundWorker to start your own EAP.
Interrupt and Abort:
- Abort:
- Tries to terminates the working thread by injecting ThreadAbortException.
- ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block.
- In catch block thread choose to cancel the abort by calling thread.ResetAbort, in this case thread didn't terminate and code block after catch will get executed.
- Also before catch finally get executed and if thread stuck in that finally block, again the thread can't be terminated or ResetAbort can be called in finally to cancel the abort.
- To terminate the thread don't call ResetAbort and code in finally should be clean.
- Main thread can choose to call join on aborting thread.
- An unhandled ThreadAbortException is one of only two types of exception that does not cause application shutdown (the other is AppDomainUnloadException).
- Useful to release a blocked thread prematurely
- The Abort method is also capable of ending a non
blocked thread—stuck, perhaps, in an infinite loop. Abort is occasionally
useful in niche scenarios; Interrupt is almost never needed.
- Interrupting a thread does not cause the thread
to end, unless the ThreadInterruptedException is unhandled.
- If Interrupt is called on a thread that’s not
blocked, the thread continues executing until it next blocks, at which point a
ThreadInterruptedException is thrown
- Methods should be designed to be interrupted.
Cleanup code in finally.
- Abort – same as interrupt except that a
ThreadAbortException is thrown instead of a ThreadInterruptedException
- The big difference between Interrupt and Abort is
what happens when it’s called on a thread that is not blocked.Whereas Interrupt
waits until the thread next blocks before doing anything, Abort throws an
exception on the thread right where it’s executing (unmanaged code excepted).
- Ideally a message should be passed to target thread for graceful termination.
- Safe Cancellation : implement a cooperative
pattern whereby the worker periodically checks a flag that indicates whether it
should abort
- Framework 4.0 provides two types that formalize
the cooperative cancellation pattern that we just demonstrated:
CancellationTokenSource and CancellationToken. These are much safer and tidier
than abort/interrupt
Lazy Initialization:
- Initialize when required, 4.0 provide
Lazy for this purpose.
- It implements Double-checked locking, i.e.
performs an additional volatile read to avoid the cost of obtaining a lock if
the object is already initialized.
- To use Lazy, instantiate the class with
a value factory delegate that tells it how to initialize a new value, and the
argument true. Argument false will let it initialize in thread unsafe manner,
good for single threaded app
- LazyInitializer: It’s an static class solves the
same purpose as Lazy . it act’s
directly on class properties so perform better and has capability to use race
condition for initialization, free of locking.
Thread Local Storage
- To keep shared variable local to thread following
techniques can be used. These avoid the need of synchronization and locking.
- ThreadStatic attribute:
- [ThreadStatic] static int _X.
- Thread static variable remain local to Thread and
exist only as the life of the thread.
- But since static field initialize only once when
static constructor is executed, only first thread will get the initialized
value others will get the null to solve this use the private property as return
value.
- This has thread affinity so This is also
problematic with Thread Pool implementation as in asp.net web / wcf as in
thread pool the thread which starts the request is not guaranteed to be the one
finishing the request specially in case of I/O or DB requests thread released
to thread pool for better throughput and after wait time other thread might
pick up the request.
- It didn’t work with instance field.
- GETDATA and SETDATA
- These are the method define in Thread Class. They
use to read/write data in application created thread slot, it’s just like a
pool where all threads read/write their values isolated from others. This can
be global across application or local to application.
- First create a slot and then call getdata and
setdata to store values in that slot.
- Thread.GetNamedDataSlot – use to create Named
slot which can be used to share data across application and LocalDataStoreSlot
creates a slot local to application.
class Test
{
// The same
LocalDataStoreSlot object can be used across all threads.
LocalDataStoreSlot
_secSlot = Thread.GetNamedDataSlot ("securityLevel");
// This property
has a separate value on each thread.
int SecurityLevel
{
get
{
object data =
Thread.GetData (_secSlot);
return data == null
? 0 : (int) data; // null == uninitialized
}
set {
Thread.SetData (_secSlot, value); }
}
·
ThreadLocal
·
New to framework 4.0
·
Work with instance field as well as default in
initialization for static field.
·
Use full in instance field ex we have to generate
Random# in a type using Random class, which is not thread safe.
·
If you have to execute some method repeatedly at
regular interval the easiest way is with the timers.
·
System.Threading .Timer – Multithreaded
·
System.Timers.Timer – Multithreaded. It wraps
System.Threading.Timer
·
System.Windows.Forms.Timer Single threaded
windows form timer
·
System.Windows.Threading.DispatcherTimer – Single
Threaded WPF timer
·
Multitheraded timers use thread pool so that few
threads serve many timers
·
This means
that the callback method or Elapsed event may fire on a different thread each
time it is called.
·
Furthermore, Elapsed always fires (approximately)
on time—regardless of whether the previous Elapsed has finished executing.
Hence, callbacks or event handlers must be thread-safe.
·
The precision of multithreaded timers depends on
the operating system, and is typically in the 10–20 ms region.
·
The single-threaded timers are not designed to
work outside their respective environments. If you use a Windows Forms timer in a Windows Service
application, for instance, the Timer event won’t fire!
·
Single Threaded times has following advantages:
·
Thread Safe
·
Tick will fire only when previous tick completed
it’s execution
·
Since event is fired on same thread, UI elements
can be updated from the Tick event handler without calling Control.Invoke or
Dispatcher.Invoke.
8.
Non Blocking Synchronization
·
Although these constructs are simple, chances of
going it wrong is high. Also acquiring and releasing uncontended lock takes
only 10-20ns.
·
Non blocking constructs also works across multi
processes.
Questions:
1.
Explain work stealing in TPL. How it works and
why? Expected answer: Explain how the core that owns the queue extracts items
on one side while a core that does not own the queue "steals" from
the other side in order to preserve CPU cache lines.
2.
I would also inquire how one might end up with an
application that is multi-threaded without ever explicitly creating a thread.
·
Event handlers can run in another thread
(SerialPort.DataReceived comes to mind, as does one or two of the three Timers
in .Net).
3.
Reentrnat:
In general, a
re-entrant block of code is one that can be entered by another actor before an
earlier invocation has finished, without affecting the path that the first
actor would have taken through the code. That is, it is possible to re-enter
the code while it's already running and still produce correct results.
In most cases, the
"actors" are threads of the same process, but the concepts of thread safety and re-entrant are
subtly different: not every thread-safe block is re-entrant, but every
re-entrant block is thread-safe. That is, re-entrancy is a stronger property
than thread safety. Here's a good
example
from Raymond Chen of how a block of code might be thread-safe but not
re-entrant.
There's a special
case when the code is recursive: the same actor is calling into the code before
its own invocation is finished, as Marc Gravell points out. All correct
recursive blocks are re-entrant; of course, not every re-entrant block is
recursive.
Wednesday, May 22, 2013
12:53 PM
Func
Delegate
Encapsulates a
method that has no parameters and returns a value of the type specified by the
TResult parameter.
public delegate
TResult Func<out TResult>()
Func<bool>
methodCall = output.SendToFile;
Func<bool>
methodCall = delegate() { return output.SendToFile(); };
Func<bool>
methodCall = () => output.SendToFile();
1. IEnumerable is the interface
that enables generic collection classes to be enumerated by using the foreach
statement. Generic collection classes support IEnumerable just as
non-generic collection classes such as ArrayList support IEnumerable.
LINQ can only worked on
IEnumerable types or it's inherit type.+
http://msdn.microsoft.com/en-us/library/7a2f3ay4(v=vs.90).aspx
|
No comments:
Post a Comment