VS.NET 2005 introduces a ToolStripContainer control which allows you to develop applications with toolbars that can be docked, undocked, reordered and otherwise rearranged to the edges of a form. This is an excellent idea, however, what was an obvious miss for the product was the ommission of a dockable window. We are all used to seeing these windows in the VS.NET IDE. The are, essentially, dockable, sizable toolwindows that can be removed, docked , undocked, resized, pinned against a border of the IDE, or unpinned. This feature has been suggested multiple times and would definitely add a professional touch to many applications. Microsoft ommitted this feature from VS.NET 2005, but perhaps if we can get enough votes, this feature will be reimplemented. Realizing that the release date is only 5 months away, its unlikely, but we can always try. Go to [I have removed the link as it is now 404/archived] to and vote for this suggestion!
Michael Howard Points to Excellent Series of Papers
Mike Howard has pointed out on his blog that there is an excellent compilation of security white papers in PDF form (image-based PDFs, not Text-based) available for download. Despite their age, these provide the very foundation for some of the most sophisticated security pillars today. Well worth the read.
Total Immersion touts ‘Augmented Reality’
This video looks way cool. It’s the presentation demo of a company called Total Immersion where they are touting their ‘augmented reality’ technology. It allows them to merge animation and objects with real-time video. I watched this demo and immediately started shuttering at the idea that Fox Sports would butcher this technology in football games. Its bad enough that they have all these strange animations and sound effects during the game, but can you imagine giving John Madden the ability to , I dunno, put costumes on players in real time? This is a far cry from just superimposing those yellow “first down” markers on the playing field.
This does, however, raise some interesting ideas. How about product placement in movies AFTER the movie has been made? What about the security issues involved? You could super-impose a gun on someone in a bank real time to frame them. OK, maybe I’ve been watching too much Sci-Fi channel lately. Anyway, this brings up very interesting possibilities that far excede those we ever imagined the first time cartoons were merged with reality in Roger Rabit.
Thread-Safe Generic Dictionary
The following question was posted on MSDN forums last night and I thought I’d take a little time to answer this considering my apparent threading affinity (*cough*). Here was the question:
“Could someone give me a pointer as to how I might implement a thread safe wrapper around a genric dictionary? I’ve written thread-safe dictionaries in C# 1.x by inheriting from the DictionaryBase but I’m a bit stumped as to how to acheive this using Generics.”
I can certainly understand the complaint here. It comes from the fact that Microsoft apparently didn’t think anyone would need thread-safe generic collections — or if you did, you should do your own work on this. Think I’m wrong? Consider this link, which states:
A System.Collections.Generic.Dictionary<,> can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread safe procedure. To guarantee thread safety during enumeration, you can lock the collection during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.
What this means is that you have some limited options. 1) Create a sub-class of System.Collections.Generic.Dictionary, 2) Create a utility class for modifying the collection safely, or 3) Creating your own thread-safe dictionary from scratch.
Lets consider these one by one.
The first option: Sub-Class
This seems a bit rediculous. Your methods might look something like the following:
using System; using System.Collections.Generic; using System.Text; using System.Threading; namespace ThreadedGenerics { class ThreadSafeDictionary : Dictionary { public new void Add(T key, U value) { // Add your preferred thread locking mechanism here base.Add(key, value); // unlocking here } // TODO : Remaining Method Implementations } }
or in VB.NET :
Imports System.Threading Imports System.Collections.Generic Public Class ThreadSafeDictionary(Of T, U) Inherits Dictionary(Of T, U) Public Shadows Sub Add(ByVal key As T, ByVal value As U) ' Add your preferred thread locking mechanism here MyBase.Add(key, value) ' unlocking here End Sub ' TODO : Remaining Method Implementations End Class
This is obviously silly because we have to override all of our functionality anyway only to wrap the call in a critical section. You should lock the underlying collection as well, but that’s up to you to decide which method you prefer.
Additionally you have to qualify the method ‘overrides’ with “New” (Shadows in VB.NET) instead of override because Dictionary<,> didn’t mark the functions as virtual. Lets go ahead and scratch this option off the list. It just doesn’t make a lot of sense and violates OO.
The second option: Create a Utility Class
This method seems to make a bit more sense. You simply create a utility class to do all the work for you and do the wrapping. Its cleaner than the “inheritance” method. (I hesitate to call anything inheritance when you can’t override the functionality but rather follow a hide-recall pattern.) This would look something like this:
using System; using System.Collections.Generic; using System.Text; using System.Threading; namespace NewWinFormsFeatures { public class ThreadSafeDictionaryUtility { Dictionary dict; public ThreadSafeDictionaryUtility() { dict = new Dictionary(); } public void SafeAdd(T key, U value) { // Add your preferred thread locking mechanism here dict.Add(key, value); // unlocking here } // TODO : Remaining Method Implementations } }
or in VB.NET
Imports System.Threading Imports System.Collections.Generic Public Class ThreadSafeDictionaryUtility(Of T, U) Private dict As Dictionary(Of T, U) Public Sub New() Me.dict = New Dictionary(Of T, U) End Sub Public Sub SafeAdd(ByVal key As T, ByVal value As U) ' Add your preferred thread locking mechanism here Me.dict.Add(key, value) ' unlocking here End Sub End Class
This should work pretty well but it isn’t the most efficient way to get what you want. It does, however, prevent you from performing much implementation. You basically only provide the implementation methods you want and you simply wrap them into a critical section or object lock.
The third option: Rolling your own
This last option requires you to create your own implementation from scratch. This would require you to create a class that implemented the IDictionary<,> interface (and any others that you want to implement such as ISerializable). I wont get into details here because to do this right, you really need to do a lot of work and its already 3am here 🙂 What I will say is that Microsoft does state that DictionaryBase is not thread safe. What it does use is the BeginCriticalRegion and EndCriticalRegion methods to let the host know that exceptions in portions of the “add” code may be damaging to other code in the AppDomain. After waking up this morning and reviewing this code (per a very kind individual who bluntly pointed out my error) I feel its neccessary to write an explaination of what those methods do and when its not appropriate. BeginCriticalSection and EndCriticalSection around the ENTIRE Dictionary.Add method would be inappropriate. Where it would be appropriate to use these functions is in this third option — rolling your own. You want it around the very small portion of the code that does the array shifting and modifying of the underlying value. Otherwise, in the case of wrapping it around the Dictionary.Add method, something as simple as an invalid argument passed into your thread-safe class may cause the entire appdomain to shut down.
HTH.
Moving Tomorrow — Feedmap Changing
Tomorrow, I am moving from Charlotte, NC to Greenville, SC. I’ll be relocating my feedmap as well. As such, I want to wish my fellow Charlotte bloggers a fond fairwell, but not a goodbye. I may be moving, but I’ll be watching you all, so no funny business!
On another note, welcome Greenville bloggers! It’s good to be back 🙂
Mike Downen has started blogging!!!
YES! Another good resource for security information has just started blogging. Mike Downen is the program manager for security in the CLR. Man, I really wish he had come with the other CLR team members to Atlanta. In any case, point your aggregators to this blog. It has the potential to provide very valuable security information.
Thread Switching Overhead
I was reading a post by Sue Loh today. It gives a very cool insight into some threading problems with an expedited thread quantum on CE. Essentially, since threads have half the time to do their actual work, the thread context switching overhead percentage provides a bigger hit on performance. Putting this in a real-world situation , I state it like this. I am currently driving 1.5 hours to work and back (each way) so I spend a tremendous amount of time on the road. Of course, I put in 9 hour days or so. Most people feel this is a lot of distance to drive, and I agree (hense why I’m moving to Greenville, SC this weekend). However, imagine if I had to drive to work in the morning, put in 4 or 5 hours of work, then drive home and back and put in another 4 or 5 hours of work. I’d be spending just about as much time going back and forth to work as I did actually working. This is the same problem with the expedited thread quantum. Sue sites the difference of 100 milliseconds that is set by default in CE to 50 miliseconds that an OEM might change this value to. Keep in mind that if you change the amount of work that can be done in a single pass, there is some overhead in the context switching that will be much more evident with the actual work cycles being truncated.
Beating the dead horse – Wireless networks again
I hate to keep beating a dead horse here, but I want to get my point across concerning wireless networking. Sans has now issued a paper about the basic insecurities of wireless. Check it out and at least use this paper as input for threat modeling your networks and wireless applications.
Who’s reading my blog? Wall Street Journal staff?
A few days ago, I blogged about wireless communications and the fact that “Friends don’t let friends use wireless“. Not two days after my post, the wall street journal posted an article about the very same thing (requires WSJ.com subscription). Granted they actually did the reporting well by researching the topic. They probably haven’t ever seen my blog, but its nice to see a national publication renouned for reporting precisely about most topics (other than political opinion) confirm my thoughts on the matter.