Asanka's blog

Back in 2000, when I left the USA and was working in Sri Lanka for a what would turn out to be a nearly two year stint at Slimline, I noticed something interesting.  Before I left, whenever people spoke of searching on the web, the names MSN or Yahoo! would inevitably crop up, since they were the dominant search interfaces* at the time.  There was some talk of Google being an emerging search provider, but it was yet to catch up with the incumbent giants.  The situation in Sri Lanka, however, was markedly different.  Everyone at Slimline was using Google for search. This was intriguing for me, specially since searching the web was synonymous with using Google (although the verb “google” wasn’t in use yet).  How was it that places like this were such early converts to Google search, seemingly so far ahead of the curve compared to USA where a majority were still stuck on MSN and Yahoo!? I don’t have a definite answer, but if I were to make an educated guess, it would be this: usabilit

If you've done any sort of multi-threaded programming on Windows, chances are you've worked with CRITICAL_SECTION s. They are lightweight and effective. However, if your critical sections are causing too much contention, they might be the cause of serious performance problems. While working on Network Identity Manager, I was curious about how all of its hundreds of critical sections are doing. Network Identity Manager is a multi-threaded plug-in based application that is often prone to contention during certain operations. But how bad is it? Critical section contention is a fact of life. It is the normal mode of operation for them. However, each time it happens, the application may pay a fairly hefty performance penalty. We are only interested in keeping contention in check. As such, we would like to know which critical sections are experiencing the highest contention levels so we can evaluate design changes that may help alleviate them. A thorough treatment on the semantic