Little DoorSince April fool’s day is coming up, I figured it was about time to do a post about the little door.

A number of years ago, my boss foolishly decided to go on vacation. Since he was gone, the obvious thing to do was to replace his office door with something a little more interesting–or at least a little more little.

Over the weekend, I press-ganged my wife and a number of the other developers to help. We removed the full size door and door frame, then framed and dry-walled in a new door. The new door was designed for a very narrow closet, and we also chopped a couple of feet off the bottom.

You can get a feel for the original size of the door by looking at the previously identical door to the left. Here is a picture of construction in progress:

Door under construction

We also managed to acquire matching paint from facilities (without mentioning what it was for–they probably figured we were covering some scuffs), added in new trim to make everything match, and painted the door hobbit-green. Here’s a shot showing me standing on the other side of the door for scale:

Standing in door

You should get a good feel for when this all happened based on the size of the cell phone on my belt (and the really nifty digital watch).

We were very proud of our workmanship, but the head of facilities was less impressed. He went completely nuts–almost cartoon-level nuts–turning red and screaming. He dragged over the CEO du jour (at that point, the company changed CEOs about as often as I got haircuts), but fortunately that particular CEO had a good sense of humor, and thought the door was great.

As for Dale, our boss–he walked in, stared at the door, then spun around and walked right out again, I think to avoid completely cracking up. He kept the door for almost a month–he said he liked the fact that everyone had to come into his office bowing. Funnily enough, Dale was in the navy, working on nuclear submarines, and I swear that he could go through the door without even slowing down.

I think that these pictures were taken by my friend Maxx Daymon, or at least with his camera (he is in some of the shots).

DisneyI have never been in a war zone or a prisoner of war camp. I’ve never lived in a slum or been abandoned in the middle of an alligator-and-mosquito infested swamp (mental note to contact SyFy with a treatment for Alliquito, The Movie).

My point is that my frame of reference is somewhat limited, so when I say that Disneyland on a weekend is probably one of the least pleasant places in the world, you should take it with a grain of salt. I’m certain that (with the possible exception of It’s a Small World) I’d rather be in Disneyland on a Saturday than, say, smeared with jam and buried in an ant pile, or forced to go to a Donald Trump rally.

In case you haven’t guessed, we were recently in California. Since we were in LA for Saturday and Sunday, we thought “why not go to Disneyland?” Seems like something you should do every 20-30 years. I suspect that, on a weekday, it probably wouldn’t have been too bad, but on Saturday, we payed $99 each to push through crowds, in order to be allowed to stand in lines. We were there for 6 hours, and in that time we managed to get on 3 rides, which works out at $33/ride.

Technically, you could argue that since we also went on the “parking lot ride” where we queued to take an uncomfortable tram to the park to stand in a queue to be searched to get in, and we also went on the “bathroom ride,” which also had an impressive queue, we might have dropped it down to a mere $20/ride.

Well, could have been worse–we might have tried to go to IKEA.

This photo is from the lobby of the Hotel Eleganté in Colorado Springs. They’ve really embraced the idea of fun–in case you can’t read it, the bed has a “try me” sign on it.

Interestingly, the hotel has a huge stone tablet with the ten commandments when you walk through the door, so this might be sending some sort of mixed message–or perhaps not. Your mileage may vary (as will that of many visitors to the lobby).

We were in the hotel for COSine 2016, a local sci-fi convention. The guest of honor was Jim Butcher of Dresden Files (and much other) fame. He is always a fun speaker, although he seemed a bit tired. The great Connie Willis was also there. If you haven’t already, you should go out and buy all of her books right now.

The other main guests were Bryan and Baxter, who are “Paranormal Claims Investigators.” I was unsure of what this meant at first, but it turns out that they are primarily researchers and debunkers of paranormal claims, and were very interesting. At some point I need to write an entry about my own time involved with such a group many, many years ago, and how I almost got murdered by the other members of the group (a hint – it will be filed in the Practical Joke category).

The convention overall was fun, although it is always a bit weird for me to be at a convention and not be required to do anything.

One thing that is strange about Cosine is that the Eleganté convention rooms are spread over a number of different floors, so you tend to have to use the slow and rickety elevators to move between programs. Also, speaking as a UI designer, whoever decided that having no indicator outside the elevators to indicate whether they are going up or down should be required to stand in the lobby and apologize to each individual rider..

Tagged with:

Hammer ShirtThis is a shirt I made a few months ago after a particularly difficult meeting!

One of the things I find funny is that people frequently don’t read the whole thing — they read the first line, and then are so sure as to what the rest of the shirt says, they don’t bother with the second.

Some of that may also be the way I formatted the shirt — if I ever remake it, I might spread the text on more lines and reduce the size of the picture.

ThreadsIt is very common with threaded applications to need to share data between threads, often in the form of dictionaries, lists, stacks, etc. However, the standard containers (generic or otherwise) in .NET are not thread-safe—if you just, say, reference a regular Dictionary<> or List<> from different threads, you will end up with some fairly hard-to-track-down bugs.

I recently worked on a project where an ArrayList was being used between threads with no sort of locking put in place and, amazingly enough, there were all sorts of hard-to-reproduce failures in the code. In general, locking code was used elsewhere, so it looked like an oversight on the part of one particular coder.

As it happens, the .NET libraries have all sorts of built-in thread-safe(ish) containers, collections, dictionaries, etc., but a lot of coders are unaware of some or all of them. This is not entirely surprising given the ways that they are exposed and the timing of their release.

Non-generic containers

This is one time when the terminology can get a bit confusing. A generic container is one that allows for the exact definition of the type of thing it contains, whereas a non-generic container is one that doesn’t do any type checking. Read that again—I assure you that it is correct!

To be more specific, generics make use of the generics functionality added in .NET 2.0, and takes the form of:

Container Example
List<T> List<string>
Dictionary<TKey, TValue> Dictionary<int, string>
Stack<T> Stack<DateTime>
Cup<T> Cup<Oolong>

As opposed to the older containers:

  • ArrayList
  • Hashtable
  • Queue
  • Stack

In general, you should always use the generic versions if you can since they provide type safety and can be faster as well. However, you might run into the non-generic versions in older code—either because it predates generics or it is post-generics, but pre-thread-safe containers! That is because there are very handy static methods that go with each of these that provide synchronized versions of the collections:

ArrayList myList = ArrayList.Synchronized(new ArrayList());

Hashtable myDict = Hashtable.Synchronized(new Hashtable());

…and so on.

These static Synchronized() methods each return an appropriate derivation from the main class that wraps each method and property in a lock. For example, if you look at the source for, say, the Count property of ArrayList, it would look like this:

public override int Count
{
  get
  {
    lock(_root)
    {
      return _list.Count;
    }
  }
}

Where _root is the SyncRoot of the contained ArrayList and _list is the ArrayList itself. Of course, you could just wrap every single call to a regular ArrayList with your own explicit lock, but it a) bloats the code and b) it is very easy to miss a spot or two.

These synchronized collections are very handy, but there are some potential issues with them:

  1. They are not generic, so you get no type-safety.
  2. The locking code wraps a call to the original method, which means that locks might not be as efficient as they could be (a completely thought-through stand-alone implementation might take advantage of the arrangement of the internal structures).
  3. Enumerating collections is not thread-safe!!

The last one is particularly likely to cause bugs because it is easy to assume that, since the collection is “Synchronized”, everything will automatically be thread-safe. This is, however, the reason why I added the “ish” when I said that these collections were thread-safe. Note that this is also true of some of the generic collections, so worth explaining in more detail.

Consider the following code:

_mySynchronizedList = ArrayList.Synchronized(new ArrayList());
//...
foreach(string str in _mySynchronizedList)
{
  DoSomething(str);
}

This code is not thread-safe! The way that foreach works is that it gets an enumerator from the underlying ArrayList, and then uses it to step through the list. Following the pattern, the call to create the enumerator is thread-safe, but the enumerator itself is not, which means that if another thread adds or removes something from the collection while you are enumerating, your results are likely to be random – either skipping items or throwing an exception–or possibly much stranger (punching a hole in the space-time continuum is not unheard of in this situation).

Of course, you can make your code thread-safe by adding your own explicit lock:

lock(_mySynchronizedList.SyncRoot)
{
  foreach (string str in _mySynchronizedList)
  {
    DoSomething(str);
  }
}

But, again, the issue here is that it is easy for future coders to forget to do this. Also, this may not be ideal—particularly if the DoSomething() method is time-consuming. If it is, then you might want to first copy the items from the list (inside your lock) and then use your copy to do the actual work – possibly testing to see if each item is still in the collection before doing anything with it (in case it was removed by another thread).

The tl;dr from all of this is that the Synchronized containers are very useful, but have their own dangers. In general, it is better to use the types of containers that tend to have atomic operations (Dictionaries, Queues and Stacks). Of course, you can enumerate all of these types of containers, but it is not as likely that you would need to.

Generic Containers

It was not until .NET 4.0 that an explicit set of generic thread-safe containers were added. Unlike with the non-generic collections, these are explicit implementations, and are all in their own namespace: System.Collections.Concurrent. The most important items in the namespace are:

  • ConcurrentDictionary<TKey, TValue>
  • ConcurrentQueue<T>
  • ConcurrentStack<T>
  • ConcurrentBag<T>

Other than the class names, these work basically the same as their non-concurrent namesakes, but with appropriate locks. Also, because of the way these are written, you can enumerate these collections! There is some fancy code in the enumeration handling to make that legal, although you are not guaranteed that the contents of the enumeration won’t change during the operation.

However, you may notice that there is no ConcurrentList<> available. The closest is the ConcurrentBag<>, which doesn’t have ordering, and misses a number of the capabilities of a List<>.

This comes back to the issues we discussed with the non-generic version of ArrayList—it is simply not possible to make an implementation of List<> that is guaranteed to be thread-safe under all circumstances without requiring outside assistance. So, it seems, Microsoft decided that it is better to not have one at all, rather than have one that would cause trouble. I agree with them, and, again, recommend that you avoid using lists between threads if you possible can use one of the other types of containers.

But…

If you absolutely, positively need to have a List<> that is shared between threads, there are some options. Interestingly, Microsoft themselves obviously decided that they needed an implementation internally, since they created an internal version for their own use (which we cannot access). But, there is also an implementation that is public:

SynchronizedCollection<T>

This collection was added in .NET 3.0, and, rather than being part of the core libraries, is implemented inside of System.ServiceModel.dll (which means that you might need to add a reference—and it might not be available for all profiles), although it is in the System.Collections.Generic namespace.

Technically, this class should be called SynchronizedList<> because that is really what it is – it works the same way as the synchronized wrapper you get from ArrayList.Synchronized() – it contains a List<T> and just puts a lock around each call to the internal implementation. It also implements the IList<T> interface, so can be used in most places that a list is required.

The nice thing is that this gives you a type-safe replacement to using ArrayList.Synchronized(), but it does suffer from the same limitations—particularly that enumeration is still not thread-safe!

 

Building thread-safe application is not easy, although the new async capabilities of .NET definitely make life simpler. However, if you have to share data containers between threads, you at least now have a fair number of options.

Tagged with: , , ,

Turn Right SignIf you don’t know where to go, turn right!

At least, I assume that is the meaning of this sign. Alternatively, the sign-maker might be a Doctor Who fan? Or, perhaps, this is how to get to a statue of the world’s largest question mark?

I took this picture in Monument, Colorado. Sorry for the poor quality, but it was taken through a windshield from a distance.

Tagged with:

MythbustersWe met the Mythbusters!!! Yesterday, Jamie and Adam’s final tour came to Denver, and we had passes (along with about 80 others) to go backstage to ask questions and pose for photos.

Admittedly, the photo looks a little bit like an identity parade, but Adam and Jamie were both extremely nice. You truly get the feeling that their personalities on-screen are really their personalities.

As for the show itself – it involved videos, demonstrations and talks on different subjects. One of the more impressive sections was them showing a series of explosions from the show, but with the sound equipment tuned (apparently with much help from Dolby) so that you could feel something of what the actual explosions felt like.

And, for the finale, Jamie brought out a paintball super-machine gun (I think it shot 500 rounds per minute), and shot at a volunteer wearing a suit of armor! Although they didn’t do this at our show, here is a link to a video of a machine the Mythbusters built to paint the Mona Lisa using paint balls in less than a second!

Adam also confirmed that they had just finished filming the last episode ever of the show. The final episodes will begin airing in January. Sad, but at least they got to control the show’s ending, rather than a network deciding to cut it off with no warning.

TardiiA while ago I blogged about 3D printing a Tardis. In fact, the Tardis on the right (the one that is lit up) is the one from that post.

But one of the cool things about 3D printing software is that it is easy to print things at different sizes, so I figured it would be interesting to try to print out the Tardis model in different sizes.

I did the little one first, and although it took a lot less time to print than the standard one (since it is only 3 inches tall) it took considerably longer to assemble. That is because of the lack of print accuracy, which is magnified greatly with smaller models.

Despite the fact that you can specify the size of things in fractions of millimeters in the software, the real world factors relating to melting plastic are simply not that precise. Assembling the mini-Tardis required quite a bit of dremeling and I had to glue everything together while compressing the pieces with rubber bands. I also had to print the lamp shade a couple of percentage points smaller than the rest of the model.

On the other hand, assembling the large Tardis was a dream—the pieces slid together very smoothly, since, at the larger scale, flaws in the medium become less relevant. On the other hand, it took well over 100 hours to print out all of the pieces, not including failed prints. Several pieces had to be reprinted because of jams (more of a problem with larger pieces when you leave the printer running without supervision) and also because I finished my spool of blue ABS and discovered that the replacement spool was not exactly the same shade!

The only thing I had to finesse on the large model was, again, the lamp shade, which is 197% of the original, rather than 200% for the rest of the pieces. The full model is just over 12″ tall. It could probably hold an action figure of one of the Doctors, if I was into that sort of thing. My wife thinks it should be either a cookie jar or a teabag holder.

I  haven’t yet added lights to the large Tardis, although that is in the works. Unlike the main pieces of the model, I can’t just scale up the light and battery holders since the LEDs and battery are a fixed size, so I will need to custom-make versions of those. I’ll probably post those on Thingiverse when done.

I also decided that I wanted a flashing light for the lantern. I’ve got the circuit for this on a prototype board (flashing away next to me as I type), but I need to transfer it to a proper circuit board. Once I’ve got that up and running, I will do an entry with the details.

Tagged with: , ,

Bishop's CastleLast weekend, at the suggestion of a friend, we drove down to Bishop’s Castle, which is about a 2½ hour drive from Colorado Springs.

Bishop’s Castle was basically built by a single guy, named Jim Bishop, over the course of the last 40-50 years, in his spare time. In fact, he is still working on it.

The architectural style can be described as whimsical, with several fairly scary staircases in either stone or metalwork. There is also a very cool dragon chimney, although it was not lit and smoking when we were there.

There is also a gatehouse with a portcullis, which would probably be fairly deadly, based on the large rock attached to it for weight. This goes over a yet-unfilled moat. I’ve included pictures of the dragon, the gatehouse and the interior below.

I have to say that this is an incredibly impressive structure, particularly for a single person to have built. It was originally self-funded, but he also takes donations.

The other interesting thing about Jim Bishop is that he is apparently on the far edge of Libertarianism, based on the various large hand-written screeds spread throughout the property. Here is an example, making it clear that the government doesn’t have the right to require drivers licenses!:

Bishop Manifesto

Never mind the legality, and the ignoring of any laws written in the last few hundred years by, last time I checked, a representative government, I have to say that I would rather that there was some form of test to make sure people actually know what they are doing before being set free on the highway. Guess that qualifies me for the ranks of the sheeple!

Here are a few additional pictures:

The dragon chimney at Bishop's Castle

The dragon chimney at Bishop’s Castle

The gatehouse at Bishop's Castle. There is a heavy stone on the portcullis. However, you can currently just walk around the whole building.

The gatehouse at Bishop’s Castle. There is a heavy stone on the portcullis. However, you can currently just walk around the whole building.

A shot from inside the castle.

A shot from inside the castle.

We didn’t make the climb up the winding stair to either of the towers since it was getting late and quite chilly, but we will hopefully get a chance to go back again when it is a bit warmer. The structure is apparently open 24×7 year round for people to wander, with donation boxes spread around. It looks like they might also do events there.

Snow - Nov 2015This is the view of our deck this morning. We have 5 foot drifts, although there’s really only about 2-3 inches of general accumulation.

Oh, and the wind is 25-40 mph. Glad I don’t have to go anywhere today!