Mel Reams

Nerrrrd

How does a thread work, anyway?

three large spools of thread, one orange, one purple, and one blue, against a white background
See what I did there? Image from pexels.com to make this post look nicer in social media shares.

Threads are used a lot in java, so I should probably understand how they actually work. They’re one of those things you use all the time without thinking about what’s really happening under the covers. I know threads and processes are related, but not exactly how.

First of all, what’s a process? To understand threads inside a process you need to understand processes first.

A process is an individual thing that’s separate from all the other processes running on your computer. In most cases a process is a single program running on your computer, but some programs have many processes – Chrome, for example, has a process for each tab. To quote the official tutorial on concurrency in Java: “A process has a self-contained execution environment. A process generally has a complete, private set of basic run-time resources; in particular, each process has its own memory space.” As I understand it, the separate memory space is the really important part of a process – this keeps processes from overwriting each other’s memory, crashing your computer, and wrecking your day.

Threads, on the other hand, are just parts of the parent process that execute semi-separately and all use the same memory. This means they can change a variable another thread just set, cause wildly bizarre bugs, and wreck your day. Every process has at least one thread, but can have more.

Okay, so why would you want to use threads when you could use processes to keep everything separate? Because processes use up a lot more system resources than threads, it’s more work to get them to communicate with each other, and they’re just overkill for a lot of problems. If you’re building in a search feature in your app and you want to search by a few different things (like name, address, and ID number) from one search box, creating a whole process for each search is way more work than you need to do when you could just use threads. Do you really want to write a whole separate program for each search? I sure don’t.

So threads are convenient, but what are they really? Saying they’re a single thread of execution through a program is all well and good, but what does that really mean? To quote stackoverflow: “A thread is a basic unit of CPU utilization; it comprises a thread ID, a program counter, a register set, and a stack.” Those things are also called the execution context, because they’re everything you need to know about the executing program to stop it and start it again in exactly the same state it was in. The CPU does that a lot so it can appear to do two things at once (if you have a multicore processor, it actually can do more than one thing at once). If one thread is waiting for data to come back from the database, which takes forever from the perspective of a CPU, the CPU will essentially make a note of where the thread got to in the code and what values all of its variables had, then start executing another thread using the “notes” it made about that one.

Because threads all share the same address space, they can share information really easily by updating global variables. In a process, a memory address (aka a variable) will probably mean nothing to another process. In a thread, any variable that’s in scope can be used and (if it’s not final) changed. This is really handy for stuff like web programming – if a thread that’s handling a particular HTTP request needs a reference to the database service, it can just grab one from the controller/servlet/general parent object that contains methods for handling individual requests.

When a thread completes, its variables get garbage collected as usual (assuming nothing else has a reference to them), you don’t have to do anything special to clean up after it.

And finally, while the tutorial I linked above talks about Thread objects and Runnables, in modern Java you mostly use CompletableFutures and let them handle starting and stopping threads for you.

Link of the day

How do you know when to take someone’s advice and when to ignore it? Today’s link lays out a few simple steps to figure out When ignoring advice makes sense. There’s no shortage or advice for programmers out there, but there’s just no way all of it works for every single programmer. If you have a process for evaluating advice, you can be sure that the advice you reject really doesn’t work for you. If you just flail around and try stuff, well maybe the things you don’t like really don’t work for you, but on the other hand maybe they just feel weird and that makes you want to stop and go back to normal before you’ve really given them a chance.

Go forth and ignore some advice, safe in the knowledge that you gave it a fair shot and it really didn’t work for you :)

JUnit tip of the day

Fun fact about JUnit tests: if something throws an exception that prevents your test from completing normally, it can’t clean up after itself. Normally this isn’t a big deal but if, for example, your setup method adds any test data to your database or creates a whole new database, you’re going to need to clean that up manually. Turns out extra databases eat up a lot of hard drive space if you don’t tidy them up for, uh, months. Just fyi :)

Link of the day

Conveniently enough, I’m not the only blogger on a “be a better programmer while still having a life” kick. If you’re interested in more tips about becoming a better programmer, check out Itamar Turner-Trauring‘s excellent post about learning more tools and techniques while you’re at work.

While you’re at it you should check out Itamar’s Software Clown newsletter, it’s full of great mistakes you can learn from and maybe even avoid running into yourself :)

Talk of the day

So it turns out there are a lot of keynotes I like, and one of them is from Keep Ruby Weird 2015 by Sandi Metz. Fair warning, parts of that talk hard to listen to – she plays recordings from an old psychological experiment that would absolutely never pass ethical review today. However, even if you skip that part (she warns you when the hard bits are coming up), there are some really excellent points in that talk about community and how to good ideas rather than conformist ideas out of your team. Seriously, it’s really worth watching.

To comment or not to comment?

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

One of many things nerds like to spend far too much time debating is whether or not to comment their code. On one hand, comments make code a lot easier to understand, but on the other, many people claim that good code is self-documenting.

If you haven’t been writing code professionally for long, it probably seems totally obvious that comments help you understand code you’re new to or haven’t looked at in a while. For the most part, they do help. The problems are that bad comments really don’t help and that comments only help if they’re correct.

What makes a comment a bad comment? If you’re going to add comments, they should explain why the code does what it does, not what it’s doing. Take the examples in this reply to a reddit thread – it’s totally unhelpful to add comments like “//Reduce’s player counter by 1” to a line of code like “mageCounter–;” That comment doesn’t add any information that isn’t in the code. Of course the counter is being reduced by 1, that’s obvious. What’s useful is knowing why the counter is being reduced.

Not only is that comment not helpful, it wastes space. The more comments like that you have, the less code you can see on the screen at once. Yes, that sounds really trivial, but seriously, it’s incredibly annoying to have to scroll up and down to see the whole method.

How can a comment be incorrect? If the code changed and the dev who changed it forgot to update the comment. Out of date comments can waste huge amounts of your time when you need to change a piece of code because everyone naturally assumes the comment is correct. If it wasn’t, why would it be there? Sadly, developers are only human and sometimes we get so excited about the code finally working that we forget to update the comment.

That’s part of why some people say that you should not have comments, that they’re a sign you didn’t name your variables and methods and classes well enough. It is true that if the names in your code are their own comments, then they won’t fall out of date the way actual comments can. On the other hand, there are limits to what variable names can tell you. I think the most important comments are the ones that explain weird code that works around a bug in an API or something strange you did for performance or just a workaround for a design choice that didn’t pan out long-term.

Those are the kind of things that self-documenting code just can’t document. There’s no method name that can explain why some of your tests use one dummy mailserver and other tests use a different one because there’s no single dummy mailserver that handles all of the test cases you need. At least, not without that method name being terrible code on its own and at that point, you might as well use a comment no matter how much you normally oppose them.

My view of comments is somewhere in the middle – I think they’re a great tool for keeping track of what you’re doing while you code, but once you’ve written the code you should only leave in the comments that are important to help understand it. As much as possible, you really should rely on good naming, if only because good names are always a good idea :)

And in general, I think absolutism is a waste of time. Even otherwise excessive “here’s what the code is doing” style comments could be really helpful if you’re working in a low level language or doing something clever with pointers where it’s just not immediately clear what the code is doing, let alone why. It’s more about context than it is about hard and fast rules. Surely you didn’t go into programming because you ever wanted to be certain about anything ;)

WordPress Appliance - Powered by TurnKey Linux