Browse by Tags
Sorry, but there are no more tags available to filter with.
-
-
[Update: Brad detected a flaw in the code: I had forgotten to initialize the _initialized field. Thanks!] [Update2: Brad detected another flaw in the code: return _instance must be outside the if. Thanks!] In the previous post we’ve seen how we can use the C# volatile keyword to guarantee that those nasty load-load reordering stay away from our code. As I’ve...
Read More...
-
-
In the last post , I’ve showed you some code I’ve written in the past and asked if there was anything wrong with it. Here’s the code again: class Lazy { private SomeObject _object; private Object _locker = new Object (); public SomeObject SomeObject { get { if (_object == null ) { lock (_locker) { if (_object == null ) { _object = new SomeObject (); } ...
Read More...
-
-
Today we’re only going to talk about the volatile keyword. The volatile keyword can be used on the declaration of a field, transforming it into a volatile field. Currently, you can only annotate a field with this keyword if it is: a reference type; a pointer type (unsafe code); one of the following types: sbyte, byte, short, ushort, int, uint, char, float or...
Read More...
-
-
In the last posts we’ve been poking around memory models, memory fences and other interesting things that might lead to the so called lock free programming. Before keep looking at how we can use those features from our C# code, I’d like to add one more example that shows how the interlocked operations might help you in the real world. Do you recall our implementation...
Read More...
-
-
In the last post , we’ve talked about memory fences. Today we’re going to keep looking at this topic, but we’re turning our attention to coding, ie, we’re going to talk about the options we have to add fences to our classes. In .NET, things are relatively straightforward. Whenever we use one of the interlocked methods we’ve met in the past, we’re adding a full...
Read More...
-
-
A few posts back, we’ve introduced the concept of load and store reordering. As we’ve seen, reordering operations exist as a way of improving performance and can be introduced on several levels (starting at compilation time and ending at runtime when the processor executes the instructions). We saw that even though things can get chaotic quickly, there are some...
Read More...
-
-
In the previous post , we’ve started looking at interlocked operations. As we’ve seen, interlocked operations are great at what they do but they won’t be usable in all scenarios (ie, don’t think that they’ll solve all your locks problems). To show how things might go awry when using interlocks, I’ll reuse a great example written by Raymond Chen a few years ago...
Read More...
-
-
As we’ve seen in the previous post , most processors give us important insurances regarding memory loads and stores. However, even though those insurances are important and can be used in several scenarios, the truth is that they aren’t enough for all real world tasks. Fortunately, most processors also offer a group of interlocked operations which enable atomic...
Read More...
-
-
In the previous post , we’ve started looking at memory loads and stores reordering. In this post, we’re going to keep our study and we’re going to introduce atomicity. Atomicity is a really important concept we’ve met in the past. We’ve already talked about it on a higher level: do you recall our discussion on critical regions (and how they’re implemented through...
Read More...
-
-
Until now, we’ve been busy talking a look at several interesting topics associated with multithreading programming. As we’ve seen, one of the most problematic areas in multithreaded programs is sharing state across multiple threads. As we’ve seen in several posts along this series, we can use a critical regions for ensuring that shared state is accessed by one...
Read More...
-
-
In the last posts of the series, we’ve been looking at many important features related to GUIs and multithreading. Today, we’re going to wrap up this topic with the BackgroundWorker class. The previous posts are really targeted at library developers. The truth is that having to implement the EAP pattern to have asynchronous behavior is simply too much work...
Read More...
-
-
In the last posts , we’ve taken a look at how synchronization contexts help marshal work across threads. Today we’re going to talk about two classes (which we’ve already met in the past when we implemented the EAP) that abstract even further the use of synchronization contexts: I’m talking about the AsyncOperationManager and AsyncOperation classes. Let’s start...
Read More...
-
-
In the previous post , we’ve started looking at synchronization contexts. In this post, we’ll take a close look at the widows forms custom synchronization context. Whenever you run a windows form app, you might end up interacting with the WindowsFormsSynchronizationContext . The constructor of this class is responsible for getting a reference to the GUI thread...
Read More...
-
-
In the last post , we’ve seen how to marshal back the results obtained on a secondary thread so that controls are updated on the GUI thread. Today we’re going to start looking at synchronization contexts. Synchronization contexts are abstractions for marshalling between threads. In other words, they abstract those scenarios where you cannot call a method from...
Read More...
-
-
In the last post, we’ve see that multithreading is almost a necessity in GUIs. We’ve also seen that there are some gotchas associated with it: a control can only be updated from the GUI thread. In practice, this means that we’ll need to marshal back the results to the main thread when they’re ready. In .NET, the Windows Forms introduces the ISynchronizeInvoke...
Read More...
-
-
In the latest posts, we’ve seen how to implement the event based asynchronous (EAP). When we introduced at the main features of the EAP, I’ve said that you should use this pattern when the consumers of your classes are GUIs programmers. Since we’ve already learned lots of things about EAP, now it’s probably a good time for starting to look at asynchronous programming...
Read More...
-
-
In the previous posts, we’ve seen how to implement the asynchronous event based pattern and how to support several features: executing the task asynchronously; support progress notification; support cancellation . Today we’re going to update our initial code to support several simultaneous asynchronous calls of the same method. If you look at that code , you...
Read More...
-
-
I know that I’ve said that the next post of the series would be on how to support several asynchronous tasks. However, I was reminded by a friend that I didn’t had any post on how to support the optional progress info feature. So, I decided to take a small detour today and we’ll see how we can modify our class so that it is able to report progress back to the...
Read More...
-
-
Today we’re going to improve the code we’ve started writing yesterday: we’re adding canceling support. As you might recall, in our last post we’ve built a simple class which supports a single asynchronous operation at a time. Since we only support one asynchronous operation at a time and we can only start one asynchronous operation from our class, then we only...
Read More...
-
-
In the last post of the series, we’ve taken a look at the main features offered by the event based pattern. Today, we’re going to look at how we can implement that pattern. We’re going to start small and we’re going to reuse the IAsyncResult sample for showing how you can implement this pattern. As we’ve seen in the previous post , we need to (at least) add a...
Read More...
More Posts
Next page »