Ok on to the next article… It was written by Jeffrey Richter. If you don’t know who that is, you are obviously not someone who has taken Windows programming seriously. That is fine if you don’t consider yourself a programmer, otherwise, please go code for the GNU folks; you shouldn’t be near Windows.
In the article Jeffrey shreds a concurrency object that is provided by the NET framework (1.1 and 2.0). I mean he demolishes it and outright says DO NOT USE THIS BECAUSE IT SUCKS. It is the ReaderWriterLock class in the System.Threading namespace. He gives several reasons not to use it but for me it came down to pathetic performance and horrible policy. Having read what he wrote I am shocked it was implemented in the way it was; were the people making that class actually people used to writing real concurrent code?
SIDEBAR FOR SMART PEOPLE WHO AREN’T PROGRAMMERS BUT STILL INTERESTED
For those that curious folks who aren’t programmers (the people who think… this is why I am not a developer) that are still with me here on this blog entry, a ReaderWriterLock is a mechanism that allows you to protect a resource when multiple threads want to access it. Hmm that isn’t doing it for me… let me go back further.
You have this resource, call it a piece of chocolate[1] ; this could be cheese or steak or a baby or even a woman, whatever floats your boat – it just needs to be something that shouldn’t be getting impacted by multiple events while you are trying to get a static image of it.
If you have multiple, we will call them people[2] that want to use that piece of chocolate for lets call it art[3]. Some people will want to just look, some others may want to move it about or even take just a tiny nibble to get the flavor and the buzz to be inspired. Well if someone is in the middle of looking, you don’t want someone turning it or nibbling on it because it just confuses the people who are simply trying to look at it.
Now you have multiple ways of handling this situation, here are some of the more popular…
The first is to ignore that a situation even exists. The chocolate (or cheese or baby or steak or woman) is turned about and has chunks missing and everyone who is standing there trying to look just tries to pretend that nothing happened and continues on their merry way. This is sort of a play on the SEP field I discussed in a previous entry. No one wants to notice that a piece of the chocolate is missing (or the girl has a big hickie) unless they themselves did it, so they try to ignore the facts in front of them. This can work to some extent for some period of time, but eventually, it will cause a catastrophe, like for instance, all of the artwork ends up looking like Picasso came to town and did all of it – and I don’t mean the good early Picasso, I mean the really off the wall stuff with 2 or 3 noses for each person that art buffs say “isn’t that incredible” about because they think that makes them appear more art buffy like since they can see something others can’t. So while viable, this is a tremendously bad mechanism because it isn’t sustainable long term. You will get bit in the ass.
The second is to have mutually exclusive locking. This is where you have to sign out the piece of chocolate to do anything with it, no one else is allowed near it when you have it signed out, they can’t even look. This definitely will make sure that everyone gets a good consistent view when they need it, the state of the chocolate may be different when they first get the lock than the last time they saw it but once they have the lock, they can do whatever they need to put it back into the shape they want it. While this will work well for consistency, it is really time consuming and can slow things down tremendously and what if the piece of chocolate wants to be seen by others even while you are seeing it? No options for the chocolate. So that brings us out to look for something else.
The third option involves having an extra piece of chocolate sitting off to the side which is a copy of the first piece. Multiple people are allowed to look at one of the pieces of chocolate but they need to ask “master” who is charge of everything (for you married men, this should be likened to your wife, for you unmarried gents, it is your mum) to see it and master will direct them to the piece of chocolate they get to look at. If someone needs to change the chocolate, then they ask master and master directs them to the second piece of chocolate. The person who needs to make changes then does so and lets the master know he/she/it is done. The master then starts redirecting people who just want to look to this new piece of chocolate. Eventually everyone who was looking at the first piece are gone and the next time they come back they will look at the second piece instead. This keeps going and hop skotches between the two pieces of chocolate. Some people really like this but it does have some drawbacks like if someone got a fresh look and someone else is still currently looking at the old piece, they won’t agree on what they are seeing. This is to be expected and needs to be worked around as it can happen with any kind of system where things are not static. It is a tradeoff between being mutually exclusive and allowing multiple lookers. This could also be implemented in a way where the second piece of chocolate is modified for some period of time by writers and is swapped out at specific times of day with the other piece. Again this can be a feasible mechanism for some artists but may not work for others.
The fourth option and where I have been trying to get to is to have ReaderWriter locks. At this point it is probably obvious what I am going to say; honestly, if you are fairly bright, all programming really eventually ends up being fairly obvious once you get past everyone’s personal coding styles, etc. A reader writer lock allows multiple people to look at the chocolate but only one person at a time can modify that chocolate in any way. While that modification is going on, no one else can see; the curtain has come down. This allows for 1-10000 or more people to look at the chocolate when it isn’t being modified, which, in general would have to be considered far more efficient if most people just want to look and don’t need to touch.
When someone wants to take a look, they go to “master” in charge of everything and ask, hey can I take a peek? The master looks to see if someone is currently writing or waiting to write and if not, says sure, here is a ticket to look (read) and then the master keeps track of that. Multiple onlookers could be present, even hundreds or thousands but since they are all just looking, there is no problem.
Now someone wants to change something so asks the master for a change (or write) ticket. The master looks to see if anyone is currently looking or changing, if so, he says hold on, I will get you a private audience. The idea that the requester gets a private audience makes him/her/it happy to wait. Once the master sees that the previous lookers or changers have all finished, it lets the new changer in and at that point will not let any others (lookers or changers) in, they all have to wait for the changer to be completed. This ensures consistency and means that the chocolate won’t be turning or missing chunks mid-look.
[1] But actually it is an area of memory or a disk file or something else that you shouldn’t be changing and looking at at the same time.
[2] But actually it is threads in a program.
[3] But it is actually about work because doing any work requires accessing resources.
The article is very clear on why you shouldn’t use the specific class mentioned, but also, it makes you wonder about the rest of the NETÂ stuff. There are a lot of bright people pointing at NET and saying, “that is FAT and ugly and slow”. Ok, maybe they aren’t saying it is ugly, but the FAT and slow comments are all over.
The kind of issues that Jeffrey points out in this core level threading object helps illustrate the problem. I am expecting there are people all over the world (read VB programmers) who thought cool, I could never do threading before and know nothing about concurrency but DotNET will handle all of it for me so I don’t have to really understand what it is doing or how good it is or if it is even right.
This just means, to me at least, we will have even more crappy coders doing even more complex stuff that they couldn’t possibly do if MSFT didn’t make it possible and since it was made possible in a crappy way, it means that much more stuff that will be out there written in a crappy way. As a person who often gets called in to try and figure out why vendor apps suck, this is just joy joy for me (not). I am getting to the point where I am going to have to learn a lot about the frameworks and NET in general just so I can figure out how people are going to screw up with it when they write their code.
Anymore I swear we are seeing less and less true software development companies and more and more people who happened to find a compiler and decided to call themselves programmers and come up with something and try to build a company around it. At least I am honest and up front on that aspect though I probably have more formal training and experience than a vast number of those out there who call themselves professionals.
Ah that’s enough for this one…
Â
 joe
Â
First rule of the way I program – get a working model going. It doesn’t have to be fast, or small, but it does have to be right, and it has to be simple enough to be certain that it’s right.
Once you’ve got it right, you can work on getting it faster, smaller, have more features, etc.
This can be one reason to start with fat and ugly.