Archive for the ‘Coding’ Category

Synchronizing the Already Synchronized in Java

Okay, so let it first be known that I’m pretty much a Java newb. I used the language a few times in school, and picked up some more of it for basic Android coding. But it wasn’t until I started my most recent job that it’s become my go-to language. Teams at Amazon are given a lot of leeway to choose their tools and the team I’m on uses primarily Perl and Java for its day-to-day coding needs.

So I was working on some code today that was showing a strangely bimodal run time. It ran “Quickly” most of the time, “Average” a little bit of the time, and “God Awful Slow Oh Sweet Jesus Why Isn’t It Done Yet” the rest of the time.

After some poking around and eventually consulting the local Java internals guru, I figured out the problem (example has been sanitized so that I still have a job on Monday):

private ThreadSafeObject tso;
...
public void synchronized timeMethod()
{
    if(tso != null)
    {
        tso.doWork();
        tso = null;
    }
}

It turns out that what was happening was that, since ThreadSafeObject is natively thread safe, there was some strange juggling going on between the Synchronized method and the ThreadSafeObject’s thread safety mutex. Basically timeMethod() ended up waiting on two sets of mutexes, which sometimes entailed a performance hit. It first had to wait on the mutex required to enter the synchronized method and then, on executing the first line of that method, had to wait for the mutex protecting the thread safety of ThreadSafeObject t.

Now it’s unclear to me exactly why this performance hit ended up being so bimodal. Perhaps someone with stronger Java-fu can help be on that point. But when the synchronized keyword above was removed, performance improved greatly and the strange bimodality of the performance profile disappeared.

Lesson: beware of synchronizing code that doesn’t need it. Not only are you losing performance for nothing, but sometimes the performance hits can be both great and strange.


Disclosure Notice

Bug, Not Feature

So in putting together that last post, I ran into an issue with WordPress. I wrote the post, pasted in the YouTube embed code for the videos I wanted, and hit publish. Imagine my surprise when the videos didn’t appear. A quick view source on the post showed that WordPress was actually stripping out my embed codes.

A little light Googling turned up nothing, so I fiddled with the parameters, double-checked my tags to make sure there were well-formed, and tried again. Still no videos.

Some more intense googling turned up a lot of people with the same problem, but no solutions and no response from WordPress. This was definitely a problem with newer versions of WP (I just upgraded this blog when I resurrected it), and someone noted that it affected users with the “Author” role, but not the “Admin” role.

Came back to the blog, bumped this account from “Author” to “Editor” status and tried again. Sure enough, the videos publish.

Now WordPress hasn’t said anything about this bug, and it’s been vocally reported in several versions of the software (since at least 2.7). This leads me to the stunning conclusion that either a.) they don’t think embedding multimedia content is important and, hence, this is a low-priority bug. So low-priority in fact that they’re not even going to comment on it, much less fix it. Or b.) they think it’s a feature.

A note to the WordPress development team. If a “feature” is both undocumented and annoying to your users, then it isn’t a feature. It’s a bug.

So to anyone out there whose youtube videos aren’t embedding in their WordPress posts because WordPress is stripping out the embed code, change your role from “Author” to “Editor” and that should fix your problem.

Hackety-Hack is Backety-Back!

The title pretty much says it all: Why the Lucky Stiff’s excellent Hackety-Hack is back online. It got caught up in the wake of _why’s disappearance and was unavailable for some time. Well, thanks to the work of Steve Klabnik, of the excellent Changelog podcast, it’s back online.

This is definitely the best way to learn to program or even just to learn Ruby. It’s definitely worth checking out for anyone and everyone, regardless of your level of coding (in)ability.

Return top

Magic Blue Smoke

House Rules:

1.) Carry out your own dead.
2.) No opium smoking in the elevators.
3.) In Competitions, during gunfire or while bombs are falling, players may take cover without penalty for ceasing play.
4.) A player whose stroke is affected by the simultaneous explosion of a bomb may play another ball from the same place.
4a.) Penalty one stroke.
5.) Pilsner should be in Roman type, and begin with a capital.
6.) Keep Calm and Kill It with Fire.
7.) Spammers will be fed to the Crabipede.