CLR
There are 5 entries for the tag
CLR
STM as an idea looks interesting and definitely has a lot of advantages over regular locking. It helps prevent deadlocks, makes easier to compose components that implement some kind of synchronization, helps eliminate nested locks, supports retries and so on. You can find the full list of goodness here. When I found out that STM.NET(based on .NET 4.0) is out my first question was related to its performance. I put together a simple test and I have to say that in most scenarios STM.NET is an overkill. Sure, it’s a research project and it hasn’t been productized which...
Actually, as many as you want, just call
Assembly.Load(File.ReadAllBytes(@"SomeFolder\MyLib.dll"));
in a loop. All copies will have their code base set to the currently executing assembly. Code base specifies the physical location of an assembly. By executing the following line
Assembly.LoadFrom(@"SomeOtherFolder\MyLib.dll");
we load another copy but this time from completely different location. Let’s add one more:
Assembly.Load("MyLib");
In this way we end up with several copies and 3 different code bases inside of the same AppDomain. This happens because each assembly is loaded into different load context. You can read about that here. Why is it like that? To be honest I’ve found no clear explanation....
At the first glance .NET events are an easy and harmless way to decouple components. The former statement is true but the latter is not. The reason is that whenever an instance of a class subscribes to an event published by another class a strong link between these two is established. By strong link I mean that the subscriber(listener) won't get garbage-collected as long as the publisher is alive. The only way to break that link is to unsubscribe from the event which might be easily omitted as the link is not explicit. Additionally there are cases when explicit(deterministic) cancellation...
Whenever there is more then one thread and more then one shared resource there must be some synchronization in place to make sure that the overall state of the application is consistent. Synchronization is not easy as it very often involves locking which very easily might lead to all sorts of deadlocks and performance bottlenecks. One of the ways of keeping out of trouble is to follow a set of guidelines. I can list at least a few sources of information worth getting familiar with: CLR, Concurrent Programming : Joe Duffy - Microsoft CLR : CLR Via C#...
As I mentioned earlier I always wanted to read C# via CLR by Jeffrey Richter. Finally I got it a few months ago and while I was sick I read it. I think it's just brilliant because: I like the way Jeffery explains problems.He is strict and precise whenever it's needed but no more. As far as I know he is not a Microsoft employee which lets him express criticism of everything that deserves it. It reveals lots of things that you will never be aware of unless you start thinking in an illogical way. Unfortunately CLR and/or C#...