Rico Mariani's Performance Tidbits : locking

Using ReaderWriterLock part 3 (last in this set)

ricom — Tue, 16 May 2006 03:32:00 GMT

Well I think it's raining ReaderWriterLocks this month! Jeff Richter has an article on MSDN that goes over a lot of the basics and some stuff that's a lot more than basic. And then there's Vance Morrison's March article on the subject as well. Lots of good stuff in both of those.

And rounding things out, there's my little series of brain teasers -- part 1 and part 2.

I've got a good number of comments with regards to the simple problem I originally posed in part 1 and the more complicated one involving a database in part 2. Thanks to all that posted or wrote!

There's some recurring themes in the comments and they tend to speak to my five original questions so I'll try to summarize them here:

ReaderWriterLock will have higher raw costs than Monitor
The amount of work done inside the lock makes a huge difference in deciding which type of concurrency control you can afford
The number of threads of each type (reader/writer) tends to matter more than the frequency of entry
Sometimes the whole locking situation can be finessed by exposing read-only objects, however,
The amount of data that is being shared limits the ability to finesse locking issues by creating read-only objects
And last but not least ReaderWriterLock can be potentially upgraded

In part 2 I answered some of the original 5 questions (keeping in mind as usual I only give approximately correct answers because complete answers would require an entire book) but here they all are again with reference to the above.

#1 Is this a good use of ReaderWriterLock? What assumptions do you have to make about the frequency of the operations.

The original code can be easily changed into an example where the write becomes atomic and the read only data is in some sort of immutable object. So it's not an especially good candidate for a ReaderWriterLock.

#2 If UpdateUsefully were the method that was called nearly always would you give the same answer?

If that were the case then really we're blocked on the write side of the reader writer lock all the time and so we're just using it as an expensive Monitor. There's not much reason for it.

#3 What if ComputeSomethingUseful were called almost exclusively instead, does that change your answer?

Here we're basically saying that read threads are very rare. If that were the case we may as well just use a Monitor (i.e. standard lock) and forget the whole thing.

#4 Is there a different approach to solve this particular problem that might be more robust generally?

Several solutions involving immutable state were offered. All of those are an excellent approach that often generalizes. I offered an example where there is too much state to readily clone.

#5 What "tiny" change could I make in this problem that would make ReaderWriterLock virtually essential?

Create a situation where the lock must be upgraded sometimes (e.g. if the result is greater than 100 then reset).

I'll leave you with one more variation on the original theme. If we must create a lock with guaranteed upgrade to writer semantics (i.e. I say that I want to be upgradeable and I want to be the next writer for sure if I choose to upgrade) how would we build that?

It might look something like this (although you could do it more effectively by building the functionality directly into ReaderWriterLock --for big units of work it won't matter much anyway).

    public class MixedUsers
    {
        private static Object myLock = new Object();

        private static System.Threading.ReaderWriterLock rw = 
            new System.Threading.ReaderWriterLock();

        private static int val1 = 0;
        private static int val2 = 0;

        // this method is called by many threads
        public static int ComputeSomethingUseful()
        {
            // disregarding timeout effects for now
            rw.AcquireReaderLock(-1);

            int result = val1 + val2;

            rw.ReleaseReaderLock();

            return result;
        }

        // this method is called by many threads
        public static int ComputeSomethingUsefulMaybeUpgrade(int v)
        {
            // note this does not block other readers
            lock (myLock)
            {
                // should we acquire the readerlock here?  
                // is it necessary?  
                // is it a good idea anyway?
                // is it a bad idea?

                int result = val1 + val2;

                if (result > v)
                {
                    // disregarding timeout effects for now
                    // this effectively waits for all readers to exit
                    // we are the only writer because we own myLock
                    // we could use UpgradeToWriterLock instead of myLock
                    // if we didn't care that another writer got in before us,
                    // but then we'd have to revalidate val1 and val2

                    rw.AcquireWriterLock(-1);

                    val1 = 0;
                    val2 = 0;
                    result = 0;

                    rw.ReleaseWriterLock();
                    return result;
                }

                // release the readerlock here if you think it must be acquired above  

                return result;
            }
        }

        // this method is called by many threads
        public static int UpdateUsefully(int v1, int v2)
        {
            lock (myLock)
            {
                rw.AcquireWriterLock(-1);  // looks redundant but is it?

                val1 += v1; // note coordination of updates
                val2 += v2; // these two sums need to happen atomically

                int result = val1 + val2;

                rw.ReleaseWriterLock();

                return result;
            }
        }
    }

There's some final code and I'll leave the analysis as an exercise to my readers. But I will say off hand that this kind of synchronization housekeeping is probably a bad idea given the very small amount of work we are synchronizing. So it's best to pretend that the body of the methods is meatier or really it's all moot.

Using ReaderWriterLock part 2

ricom — Fri, 12 May 2006 22:31:00 GMT

Well the trouble with simple samples like the one I provided in part 1 is that well... they're too simple. Some of the improvements that you can make in them won't work generally. But nonetheless I think there's some interesting discussion possibilities.

Let's have a look at it again:

    public class MixedUsers
    {
        private static System.Threading.ReaderWriterLock rw = 
            new System.Threading.ReaderWriterLock();

        private static int val1 = 0;
        private static int val2 = 0;

        // this method is called by many threads
        public static int ComputeSomethingUseful()
        {
            // disregarding timeout effects for now
            rw.AcquireReaderLock(-1);

            int result = val1 + val2;

            rw.ReleaseReaderLock();

            return result;
        }

        // this method is called by many threads
        public static int UpdateUsefully(int v1, int v2)
        {
            rw.AcquireWriterLock(-1);

            val1 += v1; // note coordination of updates
            val2 += v2; // these two sums need to happen atomically

            int result = val1 + val2;

            rw.ReleaseWriterLock();

            return result;
        }
    }

Simple enough but is this really doing what we want? Several people suggested that we could cache the result that was computed on update. That's a good idea in fact as we could do that write atomically; I won't really explore that much though because it's really quite specific to this problem. If we had other reader methods with different results we couldn't use that technique. But there is something similar we could do that does work more generally.

    public class MixedUsers
    {
        private static Object myLock = new Object();

        class MyState
        {
            int val1;
            int val2;
            MyState(int v1, int v2) { val1 = v1; val2 = v2; }
        }

        private static MyState state;

        // this method is called by many threads
        public static int ComputeSomethingUseful()
        {
            MyState s = state;

            return s.val1 + s.val2;
        }

        // this method is called by many threads
        public static int UpdateUsefully(int v1, int v2)
        {
            lock (myLock)
            {
                MyState sNew = new MyState(state.val1 + v1, state.val2 + v2);
                state = sNew;  // object write is atomic
                return state.val1 + state.val2;
            }
        }
    }

I think I like that better than the original but what about my 5 points? Can I always do this?

Well I don't think so... let me give you a different example

    public class MixedUsers
    {
        private static System.Threading.ReaderWriterLock rw = 
            new System.Threading.ReaderWriterLock();

        private static InMemoryDatabase m = InitializeTheDatabase();

        // this method is called by many threads, regularly
        public static int ComputeSomethingUseful(int param)
        {
            // disregarding timeout effects for now
            rw.AcquireReaderLock(-1);

            int result = OneSecondComputationFromData(m, param);

            rw.ReleaseReaderLock();

            return result;
        }

        // this method is called by one threads once per minute or so
        public static void UpdateUsefully()
        {
            rw.AcquireWriterLock(-1);

            ReadExternalDataAndUpdateDatabaseInTenSeconds(m);

            rw.ReleaseWriterLock();
        }
    }

Now why is that last example such a clear winner? There are several factors. What if ReaderWriterLock is 20 times lower than a regular lock, is still the right choice?

Here are the original questions, I think they're still worth discussing but I'll give some information with regard to the original posting.

#1 Is this a good use of ReaderWriterLock? What assumptions do you have to make about the frequency of the operations.

#2 If UpdateUsefully were the method that was called nearly always would you give the same answer?

If that were the case then really we're blocked on the write side of the reader writer lock all the time and so we're just using it as an expensive Monitor. There's not much reason for it. But here's a question: does it matter how often it is entered or does it matter more how many threads are doing it?

What about the last three questions, have we addressed these at all?

#3 What if ComputeSomethingUseful were called almost exclusively instead, does that change your answer?

#4 Is there a different approach to solve this particular problem that might be more robust generally?

#5 What "tiny" change could I make in this problem that would make ReaderWriterLock virtually essential?

Using ReaderWriterLock -- are you getting what you think you're getting?

ricom — Fri, 05 May 2006 21:51:00 GMT

Oh boy, more locking problems for the weekend!

Here's a more complicated lock that often gets used when it shouldn't and is avoided when it should be used. Like the other articles in this series I'll provide a bit of code and ask for comments, it's more fun that way :)

OK, here's the code:

    public class MixedUsers
    {
        private static System.Threading.ReaderWriterLock rw = 
            new System.Threading.ReaderWriterLock();

        private static int val1 = 0;
        private static int val2 = 0;

        // this method is called by many threads
        public static int ComputeSomethingUseful()
        {
            // disregarding timeout effects for now
            rw.AcquireReaderLock(-1);
 
            int result = val1 + val2;


            rw.ReleaseReaderLock();

            return result;
        }

        // this method is called by many threads
        public static int UpdateUsefully(int v1, int v2)
        {
            rw.AcquireWriterLock(-1);

            val1 += v1; // note coordination of updates
            val2 += v2; // these two sums need to happen atomically

            int result = val1 + val2;

            rw.ReleaseWriterLock();

            return result;
        }
    }

Now here are the things I want you to think about:

#1 Is this a good use of ReaderWriterLock? What assumptions do you have to make about the frequency of the operations.

#2 If UpdateUsefully were the method that was called nearly always would you give the same answer?

#3 What if ComputeSomethingUseful were called almost exclusively instead, does that change your answer?

#4 Is there a different approach to solve this particular problem that might be more robust generally?

#5 What "tiny" change could I make in this problem that would make ReaderWriterLock virtually essential?

Putting your synchronization at the correct level -- solution

ricom — Wed, 03 May 2006 20:42:00 GMT

Of course when I say "solution", I really mean "my solution" because there's not really just one way to do this. But this is an approach I like and I'll go over why I like it.

Recall the code from the original problem: (there was some very interesting discussion so it's worth clicking to see what people thought)

    public class Counter
    {
        private string name;
        private int reads;
        private int writes;

        public Counter(string _name)
        {
            name = _name;
            reads = writes = 0;
        }

        public void AddRead()
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                reads++;
            }
        }

        public void AddWrite()
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                writes++;
            }
        }

        public void WriteCounts(TextWriter tw)
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                // point #4 -- do we even like this method for this class?
                tw.WriteLine("{0} {1} {2}", name, reads, writes);
            }
        }
    }

    public class Updater
    {
        private static Counter c1 = new Counter("Category 1");
        private static Counter c2 = new Counter("Category 2");
        private static Object myLock = new Object();

        // this method is called by many threads
        public static void DoWork(bool br1, bool bw1, bool br2, bool bw2)
        {
            lock (myLock)  //  point #2, do we need this? does it even belong?
            {
                if (br1) c1.AddRead();
                if (br2) c2.AddRead();
                if (bw1) c1.AddWrite();
                if (bw2) c2.AddWrite();

                // point #3 could we change the lock so that it didn't include these two slowish statements?

                c1.WriteCounts(Console.Out);
                c2.WriteCounts(Console.Out);
            }
        }
    }

Point #1

I think it's a very bad idea to introduce locking into a low level class like this counter. It has no awareness of what is going on in the overall scheme of things. Generally classes like this with synchronization end up having redundant features that add complexity and cost for no benefit. This is exactly what is happening here. We have every expectation of having to use several of these counters in tandem and therefore synchronization within any one counter is worthless.

Point #2

The lock here is inescapable. Indeed it is fundamentally the purpose of this class to coordinate three resources -- the two counters and the output stream. Removing this lock would put the onus on some higher level code which might otherwise remain blissfully ignorant of the coordination. Now the opposite could be true: if the higher level code has to do a variety of its own synchronization then perhaps even this level is "too low" but it seems likely that this is a good fit. Note the static entry point and the presence of high level actions such as logging.

Point #3

As it is written the code is trying to coordinate three resources. Without changing the format we would be unable to decode the output in any meaningful way. Furthermore we need some form of synchronization on the output because the API itself is not threadsafe. We could lament that the writing might be slow, but since we are fundamentally required to write and it must be coordinated, just splitting the lock won't help us -- we'd simply move the blocking elsewhere. However perhaps there something that can be done to mitigate the cost. I offer one such suggestion in my solution below.

Point #4

I certainly do not like the Writing functionality at this level -- it seems rather orthogonal to the problem of keeping read and write counts. Does this really fit? See this other article for more thinking on these lines.

So what would I suggest instead? Perhaps something like this (though there are other good options)

    public class Counter
    {
        private string name;
        private int reads;
        private int writes;

        public Counter(string _name)
        {
            name = _name;
            reads = writes = 0;
        }

        public void AddRead()
        {
            reads++;
        }

        public void AddWrite()
        {
            writes++;
        }

        public void FormatCounts(StringBuilder sb)
        {
            sb.AppendFormat("{0} {1} {2}", name, reads, writes);
        }
    }

    public class Updater
    {
        private static Counter c1 = new Counter("Category 1");
        private static Counter c2 = new Counter("Category 2");
        private static Object myLock = new Object();
        private static Object myOutputLock = new Object();
        private static StringBuilder sb = new StringBuilder(4096);
        private static long sequenceNumber = 0;

        // this method is called by many threads
        public static void DoWork(bool br1, bool bw1, bool br2, bool bw2)
        {
            StringBuilder sbOut = null;

            lock (myLock)
            {
                if (br1) c1.AddRead();
                if (br2) c2.AddRead();
                if (bw1) c1.AddWrite();
                if (bw2) c2.AddWrite();

                sb.AppendFormat("{0} ", sequenceNumber++);

                c1.FormatCounts(sb);
                sb.Append(" ");
                c2.FormatCounts(sb);

                sb.Append("\r\n");

                if (sb.Length >= 4000)
                {
                    sbOut = sb;
                    sb = new StringBuilder(4096);
                }
            }

            // note other threads can keep doing the main job
            // this thread becomes the output worker temporarily
            // you could do real async i/o here if you wanted
            // output could be out of order but sequence number allows decoding
            if (sbOut != null)
            {
                lock(myOutputLock)
                {
                    Console.WriteLine(sbOut.ToString());
                }
            }
        }
    }

And can you think of three reasons why I like that better? :)

(Also it needs a simple flush method to handle shutdown -- left as an exercise for the reader :))

Putting your synchronization at the correct level

ricom — Mon, 01 May 2006 21:43:00 GMT

Continuing in what's turned into my series on locking advice, I have a new example for you of a typical problem that happens in class design. As usual I've simplified this almost to the point of being silly to illustrate the problem. Hopefully the crux of what is going on still shows through.

The theme for today is that often synchronization is inserted into the wrong level of programming code. Low level classes, like the Counter in this example, have very little idea what is going on in the world around them and so they can't make especially good synchronization decisions.

Often synchronization at the low level ends up doing nothing useful, but instead only creates complexity and wastes cycles. My "favorite" example of this is the availablity of synchronized collection classes which, like the Counter example below, have difficulty meeting the synchronization needs of their clients because they have no understanding of the overall unit of work and are therefore unhelpful when composed with other resources.

    public class Counter
    {
        private string name;
        private int reads;
        private int writes;

        public Counter(string _name)
        {
            name = _name;
            reads = writes = 0;
        }

        public void AddRead()
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                reads++;
            }
        }

        public void AddWrite()
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                writes++;
            }
        }

        public void WriteCounts(TextWriter tw)
        {
            lock(this) // point #1 -- do we like the three lines marked point #1 ?
            {
                // point #4 -- do we even like this method for this class?
                tw.WriteLine("{0} {1} {2}", name, reads, writes);
            }
        }
    }

    public class Updater
    {
        private static Counter c1 = new Counter("Category 1");
        private static Counter c2 = new Counter("Category 2");
        private static Object myLock = new Object();

        // this method is called by many threads
        public static void DoWork(bool br1, bool bw1, bool br2, bool bw2)
        {
            lock (myLock)  //  point #2, do we need this? does it even belong?
            {
                if (br1) c1.AddRead();
                if (br2) c2.AddRead();
                if (bw1) c1.AddWrite();
                if (bw2) c2.AddWrite();

                // point #3 could we change the lock so that it didn't include these two slowish statements?

                c1.WriteCounts(Console.Out);
                c2.WriteCounts(Console.Out);
            }
        }
    }

What are your thoughts on the marked points (1-4)? What would a better Counter class look like to meet the needs of DoWork?

(my "solution" is now available here)

Simplify your locking strategy -- simpler is better

ricom — Sat, 29 Apr 2006 01:29:00 GMT

Well I didn't mean to but it seems I'm writing a series of articles on locking.

Based on my last posting I got several requests for a simple example of a case that could be improved with simpler locking. Here's something of that ilk that's similar to something I encountered in The Real World. The 2nd choice is based on what I recommended.

    class FreeThreaded1
    {
        private static volatile Dictionary  dict = new Dictionary();

        static void UpdateThreadProc() // one thread runs this
        {
            for (;;)
            {
                using (StreamReader sr = new StreamReader("c:\\pickupdir\\dictionary.txt"))
                {
                    lock (dict)
                    {
                        dict.Clear();

                        String line = null;

                        while (null != (line = sr.ReadLine()))
                        {
                            int iTab = line.IndexOf('\t');

                            if (iTab < 1 || iTab > line.Length-2)
                                continue;

                            string key = line.Substring(0, iTab);
                            string val = line.Substring(iTab+1);

                            dict.Add(key, val);
                        }
                    }
                }

                System.Threading.Thread.Sleep(5000);
            }
        }

        static string ReadEntry(string s)  // this is called by many threads at random
        {
            lock (dict)
            {
                return dict[s];
            }
        }
    }


    class FreeThreaded2
    {
        private static volatile Dictionary  dict = new Dictionary();

        static void UpdateThreadProc() // one thread runs this
        {
            for (;;)
            {
                using (StreamReader sr = new StreamReader("c:\\pickupdir\\dictionary.txt"))
                {
                    Dictionary d = new Dictionary();
                    String line = null;

                    while (null != (line = sr.ReadLine()))
                    {
                        int iTab = line.IndexOf('\t');

                        if (iTab < 1 || iTab > line.Length-2)
                            continue;

                        string key = line.Substring(0, iTab);
                        string val = line.Substring(iTab+1);

                        d.Add(key, val);
                    }
                    dict = d;
                }

                System.Threading.Thread.Sleep(5000);
            }
        }

        static string ReadEntry(string s)  // this is called by many threads at random
        {
            return dict[s];
        }
    }

Can you spot at least 3 reasons why I would like the 2nd one better? Not that it's perfect...

Locking -- Isolation -- Unit of Work -- Performance -- Solution

ricom — Thu, 27 Apr 2006 08:33:00 GMT

A few days ago I posted a concurrency problem for commentary and I got a very nice set of responses.

Now I can't say that there is any answer to this problem that I would say is universally correct but there are some interesting observations that we can/should make about the proffered code. Many of these points were covered in the commentary but not everything was so hopefully you’ll still find it interesting to read this. Again, as always, forgive me for generalizing in the interest of greater clarity in some cases below.

Now the first solution had one lock controlling all the access. This has perhaps the most understandable behavior of the two solutions and maybe about as understandable as we can get.

    // it's easy to explain what this does
    class ExampleCoarse
    {
        public ExampleCoarse() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(StreamWriter sw)
        {
            lock(myLock)
            {
                long ticks = DateTime.Now.Ticks;
                int count = IncrementCount();
                LogToStream(sw, ticks, count);
            }
        }

        private int IncrementCount()
        {
            return ++count;
        }

        private void LogToSteam(StreamWriter sw, long ticks, int count)
        {
            sw.WriteLine("{0} {1}", ticks, count);
        }
    }

The first thing to notice is that I said in the assumptions that there was only going to be one instance of this object – and yet the object has no static members. Presumably that was done to allow for several logically independent copies of the object at some point in the future. If the “count” and “myLock” members were truly static then the single instance choice would be locked in forever. As it stands the users of the object are sort of forced to deal with the fact that there is some shared instance because they must provide the “this” pointer. Fair enough I suppose.

But even in this simplest form of the code there are at least two other concerns. It appears that writing to the stream will be serialized … but will it? Well not exactly. The StreamWriter (sw) provided is external to the class. We have no idea if it is going to be shared by other threads. If it is then it will have to be the case that this is the only place that StreamWriter is used because otherwise lock(myLock) will not offer any protection (see “Same Resource, Same Lock or else locking won't give you the protection you need” for more details on this).

That’s bad enough. But can we say that it is wise to even use the external StreamWriter? What does it do? The trouble with StreamWriters is that they abstract the underlying stream with a nice interface. Coincidentally that’s also what’s good about them. So what is going to Actually Happen when we call sw.WriteLine()? Well the answer is pretty much anything could happen. For all we know the underlying Stream synchronously sends a letter to Grandma via US certified return-receipt air mail. So is it a good idea to call such a method inside a lock? Well… if we have a good understanding of what the stream is going to be for other reasons (not shown here) then maybe. But if this was framework code, it might be an astonishingly bad idea indeed.

Looks like for even the simple code, as written, to get good results it needs to make some pretty significant assumptions.

Let's have a look at the second version now:

    // it's not so easy to explain this... or how to use it.. but is it better?
    class ExampleFine
    {
        public ExampleFine() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(StreamWriter sw)
        {
            long ticks = DateTime.Now.Ticks;
            int count = IncrementCount();
            LogToStream(sw, ticks, count);
        }

        private int IncrementCount()
        {
            int c = System.Threading.Interlocked.Increment(count);
            return c;
        }

        private void LogToSteam(StreamWriter sw, long ticks, int count)
        {
            lock (myLock)
            {
                sw.WriteLine("{0} {1}", ticks, count);
            }
        }
    }

That's of course more complicated, but what does it do? Well naturally it has all the same issues as the "easy" case. But additionally it suffers from the fact that it's basically impossible to characterize the output. Counts and ticks do not necessarily increase together and they can also be out of order in the file. The count could be arbitrarily unrelated to the ticks. Is it at least faster? Hrm... maybe... it does have finer locks but then the interlocked operation isn't cheap either and we don't know if the stream is fast (like say a memory stream) or slow (like that letter to Gramma). If the streaming operation is comparatively quick then contention would be low and the extra locks would just slow us down. On the other hand a very slow stream will dominate the cost as everyone is gonna be waiting for Gramma for so long that the rest of the time isn’t going to matter a whit. So somewhere in between there would be a cutoff where the extra concurrency is paying for the extra locking.

Wow that’s complicated.

So in return for getting streamed output that’s totally meaningless we get…maybe nothing at all. And don’t forget the Gramma stream could be asynchronous – further confusing the situation for both cases.

I’m not really liking that second choice very much at all at this point.

Could we do better? Yes I think we could. Here’s a couple of suggestions:

    // it's easy to explain what this does
    class ExampleHybrid
    {
        public ExampleHybrid() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(StreamWriter sw)
        {
            lock(myLock)
            {
                long ticks = DateTime.Now.Ticks;
                int count = IncrementCount();
            }

            LogToStream(sw, ticks, count);
        }

        private int IncrementCount()
        {
            return ++count;
        }

        private void LogToSteam(StreamWriter sw, long ticks, int count)
        {
            sw.WriteLine("{0} {1}", ticks, count);
        }
    }

In this case we’re basically coming right out and saying to our callers that the StreamWriter (sw) they provide us better not be shared with other threads, or else it better be internally threadsafe. Either way we’re staying out of it. And by the way we aren’t guaranteeing the output order but we are guaranteeing that at least the tick will match the counts in some meaningful way. It’s an interesting compromise – and actually easier to understand than the previous case. If the stream is slow at least we won’t be holding a lock while it does its business.

And maybe one last choice for discussion

    // it's easy to explain what this does
    class ExampleNoOutput
    {
        public ExampleNoOutput() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(out long ticksOut, out int countOut)
        {
            lock(myLock)
            {
                ticksOut = DateTime.Now.Ticks;
                countOut = IncrementCount();
            }
        }

        private int IncrementCount()
        {
            return ++count;
        }
    }

And in this last example we finesse the output issues by declining to take a dependence on the stream entirely. “Leave me out of your output logging problems”, says this class, “I wash my hands of all that messy I/O”.

This could perhaps be the wisest course of all. Although the services are more modest they are readily understood and any desired logging strategy can be built on top of them. Whatever chuncking, synchronization, etc. is up to higher level code that is likely be better capable of making that decision intelligently. Moving synchronization primitives “up the stack” to code with more overall “awareness” of what is going on is a common theme to get more sensible synchronization. Definitely something you should keep in mind.

Is there an overall winner? Hardly. Though I think the second of the two original versions is probably the overall loser.

Thanks very much for the thoughtful comments on the first posting.

Locking -- Isolation -- Unit of Work -- Performance

ricom — Tue, 25 Apr 2006 05:54:00 GMT

I've had a bit of a locking/threading theme in some of my recent postings so I thought I'd continue that with a little problem. Here's a (simplified) set of operations that is sort of an example of what you might need to do in a free threaded class. Let's assume there is one instance of this class that is to be shared between multiple threads any of which might call the DoIt() function at any time.

Here are two possible implementations that are like things I've seen in the past. The question is: Which of these is "better?" Is there something that is (in some sense) better still? What are the factors that influence this decision (Hint: see the title of this posting)

You might have to scroll down to see the code depending on your browser because the <PRE> formatting seems to come out weird with the stylesheets in use here.

    // it's easy to explain what this does
    class ExampleCoarse
    {
        public ExampleCoarse() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(StreamWriter sw)
        {
            lock(myLock)
            {
                long ticks = DateTime.Now.Ticks;
                int count = IncrementCount();
                LogToStream(sw, ticks, count);
            }
        }

        private int IncrementCount()
        {
            return ++count;
        }

        private void LogToSteam(StreamWriter sw, long ticks, int count)
        {
            sw.WriteLine("{0} {1}", ticks, count);
        }
    }

    // it's not so easy to explain this... or how to use it.. but is it better?
    class ExampleFine
    {
        public ExampleFine() {}
        private Object myLock = new Object();
        private int count;

        public void DoIt(StreamWriter sw)
        {
            long ticks = DateTime.Now.Ticks;
            int count = IncrementCount();
            LogToStream(sw, ticks, count);
        }

        private int IncrementCount()
        {
            int c = System.Threading.Interlocked.Increment(count);
            return c;
        }

        private void LogToSteam(StreamWriter sw, long ticks, int count)
        {
            lock (myLock)
            {
                sw.WriteLine("{0} {1}", ticks, count);
            }
        }
    }

Same Resource, Same Lock or else locking won't give you the protection you need

ricom — Thu, 23 Mar 2006 04:49:00 GMT

I sometimes see funny locking patterns because there is a mental assumption that the lock keyword (via Monitor features of the runtime) automatically guards the contents of the locked region. This isn't the case. All that is guaranteed is that only one thread can hold the monitor (i.e. the locked object) at any moment. This doesn't result in resource protection at all unless you, by policy, always take the same lock when accessing the same resource.

So here are some (vastly simplified) examples that work:

class T1
{
   private static Object myLock = new Object();

   private Object member1 etc. etc.
   private static Object member2 etc. etc.

   public void DoSomething(T1 him)
   {
       lock (myLock)
       {
        ... use this.member1, him.member1, or member2 // safe
       }
   }
}

class T2
{
   private Object myLock = new Object();
   private Object member1 etc. etc.

   public void DoSomething()
   {
       lock (myLock)
       {
        ... use this.member1 but no other member1 from any other object // safe
       }
   }
}

And here are some (vastly simplified) examples that do NOT work:

class T3
{
   private Object myLock = new Object();

   private Object member1 etc. etc.
   private static Object member2 etc. etc.

   public void DoSomething()
   {
       lock (myLock)
       {
        ... use member2 // this is not safe
       }
   }
}

class T4
{
   private Object myLock = new Object();
   private Object member1 etc. etc.

   public void DoSomething(T4 him)
   {
       lock (myLock)
       {
        ... use him.member1  // not safe
       }
   }
}

class T5 // the most nefarious of them all
{
   private Object myLock = new Object();
   private static Object myOtherLock = new Object();

   private Object member1 etc. etc.

   public void DoSomething(T1 him)
   {
       lock (myLock)
       {
        ... use this.member1 // not safe due to DoSomethingElse
       }
   }

   public void DoSomethingElse()
   {
       lock (myOtherLock)
       {
        ... use this.member1 // not safe due to DoSomething
       }
   }
}

Of course locking choices can have profound performance ramifications but that's not really the point here. The thing to remember is that locking alone generally does not provide protection -- you get protection by applying a consistent locking policy to a resource or set of resources.

Sometimes, in the name of performance, complex locking schemes get invented but then race conditions are introduced so correctness goes out the window. It's always important to remember that, as I'm fond of saying, "It's easy to make it fast if it doesn't have to work."