Skip to main content

Posts

Limiting Threads in a ThreadPool

The ThreadPool class supports methods for setting the number of minimum and maximum thread in the thread pool. In most circumstances, yhe number of threads is the pool is set at optimum numbers. If you find that your application is being constrained by the threads in th thread pool, you can set the limits yourself. There are two types of situations where you will want to change the thread pool thread limits: thread starvation and startup thread speed. In thread-starvation scenario, your application is using the thread pool but is being hampared because you have two many work items and you are reaching the maximum number of threads in the pool. To set the high watermark of threads for your application, you can simply use ThreadPool.SetMaxThreads. In cases where the startup costs of using the thread pool are expensive, increasing the minimum number of threads can improve performance. The minimum number of threads dictates how many threads are created immediately and set to wait for

Deploying COM-Enabled Assemblies

Although an assembly can be created visible to COM, one should follow below guidelines to ensure that things work as planned: All classes must use a default constructor with no parameters. Any type that is to be exposed must be public. Any member that is to be exposed should be public. Abstract classes will not be able to be consumed. After these criteria are met, the assembly is essentially ready to be exported. There are two mechnisms to do so. One can use VS or a command line utility(TlbExp.exe). First you need to compile the type through Visual Studio's build mechanism or through command line compiler as               csc /t:library ComVisiblePerson.cs Next you need to use Type Library Exporter Utility. This should be done from VS command prompt:               tlbexp ComVisiblePerson.dll /out:ComVisiblePersonlib.tlb Next oyu need to create  resource script (ComVisiblePerson.res) with the following Interface Definition Language (IDL) definition:               IDR_TYPE

Moving a type (i.e. class) to another assembly

In .NET, one often refers to other assemblies that contain specific modules that you can use in your application. Say, you reference a DLL that contains some classes that you will use in your application. Suppose the application is deployed. Now, suppose you want to move one class of the DLL to another assembly. What can you do in this situation with old coding methodoligies? The old methodologies say, Remove the class from the existing DLL. Create another DLL (assembly) using that class. Recompile both the DLLs. From your application, add a reference to the new DLL. Recompile the application. Re-deploy the whole thing. Wouldn't it be nice to leave the deployed application untouched, and make whatever changes are needed in the DLLs? Obviously, that would be nicer. That's where the TypeForwardedTo  attribute comes into the scene. By using this, you can move your necessary classes out to a new assembly. Now, when your application looks for the class in the old DLL, th

Running one process on multiple processors

A thread in a process can migrate from processor to processor, with each migration reloading the processor cache. Under heavy system loads, specifying which processor should run a specific thread can improve performance by reducing the number of times the processor cache is reloaded. The association between a processor and a thread is called the processor affinity. Each processor is represented as a bit. Bit 0 is processor one, bit 1 is processor two, and so forth. If you set a bit to the value 1, the corresponding processor is selected for thread assignment. When you set the  ProcessorAffinity  value to zero, the operating system's scheduling algorithms set the thread's affinity. When the  ProcessorAffinity  value is set to any nonzero value, the value is interpreted as a bitmask that specifies those processors eligible for selection. The following table shows a selection of  ProcessorAffinity  values for an eight-processor system. Bitmask Binary value Eligible

WebSite vs WebApplication

The only similarity between a web site and a web application is that they both access HTML documents using the HTTP protocol over an internet or intranet connection. However, there are some differences which I shall attempt to identify in the following matrix: Web Site Web Application 1 Will usually be available on the internet, but may be restricted to an organisation's intranet. Will usually be restricted to the intranet owned by a particular organisation, but may be available on the internet for employees who travel beyond the reach of that intranet. 2 Can never be implemented as a desktop application. May have exactly the same functionality as a desktop application. It may in fact be a desktop application with a web interface. 3 Can be accessed by anybody. Can be accessed by authorised users only. 4 Can contain nothing but a collection of static pages. Although it is possible to pull the page content from a database such pages are rarely updated after they have been crea

Are cloud storage providers good for primary data storage?

Why not use a cloud storage provider? The most persuasive argument against using cloud storage for primary storage  is application performance. Application performance is highly sensitive to storage response times. The longer it takes for the application's storage to respond to a read or write request, the slower that application performs.  Public cloud storage by definition resides in a location geographically distant from your physical storage when measured in cable distance. Response time for an application is measured in round-trip time (RTT). There are numerous factors that add to that RTT. One is speed of light latency, which there is no getting around today. Another is TCP/IP latency. Then there is a little thing called packet loss that can really gum up response time because of retransmissions. It is easy to see that for the vast amount of SMB(small mid sized business) primary applications, public cloud storage performance will be unacceptable.  When do cloud storage

Encapsulation: Local change - Local effect principle

One of the central principles of object oriented programming is Encapsulation. Encapsulation states that the implementation details of an object are hidden behind the methods that provide access to that data. But why is encapsulation a good idea? Why bother to do it in the first place? Just stating that it's "good OO design" isn't sufficient justification. There is one primary justification of encapsulation. It's a principle I call "Local Change - Local Effect". If you change code in one spot, it should only require changes in a small neighborhood surrounding the original change. When used properly, encapsulation allows software to change gradually without requiring bulk changes throughout the system (Change of code in one place requires code change in many places is known as Domino effect). Encapsulation helps follow this principle by allowing changes in the representation of an object's state. The methods for the object may be affected, but ca