9:10am (ME) - Databinding in WPF - interesting information about DataBinding. Very good so far. Tip for getting more information abou the DataBinding and run time in the Output windows use the
PresentationTraceSource
10:01 am (ME) - Performance tip.. he says ALWAYS set your DataContext for databinding in Code.. big performance help.. usually in the OnLoaded or Loaded event.
10:42 am (MC) -I'm at the day of threading presentation today. Here are some notes I've taken on the first of the 4 sessions.. I dont know how much sense any of this will make :D
Creating processes incurs way more overhead than creating thread. Creating threads does cause notification of every referenced assembly which does incur some overhead. (DLL attach/detach notifications).
Context switch - A context switch occurs when window switches thread execution. Context switches happen about every 20ms. If windows switches to a thread owned by another process it creates overhead in translating all the virtual addresses for the process memory to physical addresses.
1:47pm (ME) - Lunch was ok.. same as last 2 days.. not great. The give aways sucked.. really disappointed about that.
In a WPF 3D talk, very interesting shows a lot of different examples that look good. I will post the code in a little bit as well.
(rumor) Windows 8 is going to provide a framework that helps eliminate the ability to easily create syncronized threads and encourage async code and thread creation.
feature cut from vista that would of allowed several different managed applications under the same process, which would allow them to share the same instance of CLR components.
Process an Appdomains - A process is a container for code and data, esentially address space (A windows concept). AppDomains are a CLR concept. AppDomains logically sub divide a processes virtual address space. They are created/destroyed more cheaply than a process. Also provides managed exe/dll code & data isolation. AppDomains allow you to control CAS. Threads are not automatically created for each AppDomain. Only thread execute code, not the AppDomain, it is just a container. One managed heap is created per process but an appdomain ownes the objects its code creates in the manage heap, and those objects cannot be shared across app domains. Static fields and singletons are per AppDomain, not per process.
Threads - every thread created has 1MB of committed user-mode memory and 12Kb/24KB of kernel memory on the stack. This stack is used for parameters and local variables. Threads are confined to a single process address space, they cannot execute code or access data from other processes.
When a process dies, all threads die.
In the CLR threads can cross AppDomain boundaries. Although it can only execute in one AppDomain at a time and it will assume the current AppDomains security and configuration settings.
A tool called process explorer allows you to view the number of AppDomains running inside a process. Its like task manager on crack. It can also display number of context switches. You can download it at http://Sysinternals.com.
Creating a thread - .net thread objects are light-weight, constructing one doesn't have windows create a thread. Calling the Start() method causes windows to actually create the thread. Once your delegated method returns windows will kill the thread. Optional: You can call Join() on a thread in .net to pause the current thread execution until your new thread is completed executing.
The CLR run time creates 2 threads in addition to the default one created initially by the process. Debugging in Visual studio also creates an additional thread for running debug events.
Whenever garbage collection starts it suspends all the threads, walks and compacts their stacks, and then resume all of them. Garbage collection can become very painful with a large number of threads.
10:53 am (ME) - In the 2nd DataBinding method, and talking about ValueConverters, it is interesting. I'm going to try and post the slides for Threading and Binding now.
11:17am (ME) - Here is are the current slide decks that we are in, and used for the rest of the day.
DataBinding - Part 1 - http://download.sharethispoint.com/Data-Binding%20in%20WPF-Part%201.pdf
Part 2 - http://download.sharethispoint.com/Data-Binding%20in%20WPF-Part%202.pdf
Day of Threading - Part 1 - http://download.sharethispoint.com/Day%20of%20Threading%20-%20Part%201.pdf
Part 2 - http://download.sharethispoint.com/Day%20of%20Threading%20-%20Part%202.pdf
Part 3 - http://download.sharethispoint.com/Day%20of%20Threading%20-%20Part%203.pdf
Part 4 - http://download.sharethispoint.com/Day%20of%20Threading%20-%20Part%204.pdf
10:42 am (MC) -
Reasons to create threads – Isolate code from other code for reliability and allow easier creation of code for certain tasks. Concurrent execution on multi-cpu machines.
Examples of good usage for threads:
· Indexing files
· Defrag disks
· Building source code in the bg to provide error lists
· Spelling/Grammer checking
· Copying/printing files.
· Resizing an app window while processing I/O
Internally every thread has a base priority number which ranges from 0(lowest) to 31(highest). 0 is reserved. Windows schedules highest priority threads to run on the cpu first. Most threads in the system run on priority 8.Priority doesn’t affect the speed at which your code runs, it just affects the frequency at which your thread is scheduled for execution. The CLR has priority 1 and 15 reserved. OS threads run in the real time range and any threads you create in that range can adversely affect the OS. You must be admin to run threads as real time.
Environment.ProcessorCount will tell you how many processors are on the machine.
The CLR creates a thread pool. There is one thread pool created for each process. The thread pool facilitates the reuses of threads to help alieviate the overhead associated with creating a new thread.
Interlocked.Increment does a thread safe, atomic, increment on a variable.
Process.ProcessorAffinity tells windows and the thread pool the max number of processors to use.
1:47pm (ME) - Lunch was same as the last few days.. nothing great.. .and the giveaways were not great at all this year.. In the middle of a WPF 3D presentation.. some very kewl models and how to do it.. trying to see practical approaches to it. I will post the code later.
3:19 pm (MC) -
Windows I/O completion port – eliminates thread blocking when accessing drivers/hardware. The thread pool is connected to and works with the I/O completion port. The CLR creates 1 IOCP per process.
In vista and windows server 2008 they have added support for I/O priorities. Basically adds several IRP ques to each I/O device. You can PInvoke them from .net.
Asynchronous Programming Model – Supports 3 rendezvous techniques
· Wait until done – sux, blocks thread entirely, just like normal read.
· Polling – sux, could block the thread. Allows you to loop or check a variable for the status of the I/O completion.
· Callback method – the way to go.
Used with the “Begin” and “End” naming conventions. Ie: BeginRead and EndRead of the filestream object.
Every “Begin” method always has two extra params, AsyncCallBack and an object. Each Begin method returns a IAsyncResult object, which is like your recipt for making the request.
If you don’t specify FileOptions.Asynchronous flag BeginRead just creates another thread in bg to simulate asyn I/O. This is really bad, so you should always specify the flag if u want Async operations.
4:53 pm (MC) -
Web services support async operations out of the box by using the “Begin” and “End” method names on your web methods. Automatically uses the thread pool.
Silverlight does not offer an synchronous APIs and there are people on the windows team trying to convert all the legacy synchronous APIs to async.
Make sure to check out the asyncenumerator. Make writing async methods look just like one synchronous method. It uses the SynchronizationContext object on a thread to make sure that you don’t have call BeginInvoke with code inside your iterator and other mechanisms to allow your code to be used by threads other than the owner. Powerthreading library here: http://wintellect.com/powerthreading.aspx Looks really bad ass.
I need to look at reader/writer locks. Reader/writer/gate might be a possible answer to this problem.
Class given by Jeffery Richter from www.wintellect.com.