When you have a set of highly parallelizeable work, executing it concurrently can be easy:
Of course you’d probably want to track the work at least so you know when it’s done:
Calling Task.Run schedules the work to run on the .NET ThreadPool which is highly tuned and can likely get the work done as fast as you have CPUs to do the work as it tends to schedule at least as many threads as the machine has CPU cores.
When you write multi-threaded code, it’s important to be aware of whether the code in other libraries you call into is also thread-safe. By my observation, most code written is not thread-safe. So if you’re writing thread-safe code, kudos to you.
Task and Task in .NET 4.0 are absolutely awesome types and they provide the basis for async support that came in .NET 4.5. One somewhat unexpected behavior they have that can occasionally cause bugs in your code is that when a Task completes,
The Android SDK Manager requires a GUI and tedious searching for the SDKs that you want to install. There is a command line android.bat script that lets you install and uninstall these without the GUI but it’s based on an ordinal index for each SDK so you have to run the script once,
I was able to work out a model for continued open source development of ImmutableObjectGraph — at least in a limited way. This means that the 16 month silence on the public repo is over, and I was able to push a bunch of the commits I had been keeping internal to the public.
When a method may throw for more than one reason, the thoughtful programmer might ask “which exception should be thrown?”
Consider a method which performs argument validation, is cancelable, and also might throw based on the state of the object. What order should these validations occur so that the best exception is thrown?
Everyone appreciates a fast and responsive UI, and Visual Studio is no exception. Extensions that run in Visual Studio play a significant role in how responsive the IDE will be for its users. Visual Studio has been evolving over the past few cycles to not only improve performance,
Whether you’re doing async work or not, accepting a CancellationToken as a parameter to your method is a great pattern for allowing your caller to express lost interest in the result.
Supporting cancelable operations comes with a little bit of extra responsibility on your part.
In my last post, I introduced a T4 template that constructs efficient and quite capable immutable objects based on the simplest mutable type definition. I also mentioned that the published sample is (necessarily, ala T4 style) open source and hosted online.
We’re all familiar with immutable collections now. But immutability is only as immutable as it is deep. And an immutable collection of mutable objects may not provide the depth you’re looking for. So how can one create an immutable object?
Suppose you would define the mutable version like this:
1 2 | public class Fruit { public string Color { get; set; }<br />} |
An immutable version might be defined like this:
1 2 3 4 5 6 7 8 9 10 11 | public class ImmutableFruit { private readonly string color; public ImmutableFruit(string color) { this.color = color; } public string Color { get { return this.color; } } } |
Now that’s fine for very simple objects.
