This is a feature not many coders will be using right away, if at all. In fact, there's still a debate over whether or not this feature is even useful, and it only has limited use on the official Ruby implementation (and slightly more use on JRuby).
Thread safety is the ability to split the task of handing a request, fetching the data and rendering the page into a number of parallel threads and still have it behave correctly. This involves a number of locks (called a "mutex" or mutual exclusion lock) on shared resources and the careful management of variables and shared resources. Rails 2.2 has finer-grained thread safety than earlier versions of Rails.
So what does this mean and how can you use it? Theoretically, this can allow you to split the workload of rendering a page across multiple cores and CPUs and reduce the total execution time. A good example is rendering partials. If a page has 7 partials to render, a number of threads (one per processor core, or maybe even more) can be created to do this in parallel, making your application run much faster.
The problem until now has been the "one giant lock" problem. There was one mutex on the entire process of rendering a page, and Rails had no opportunity to parallelize the process. Now, the problem on Ruby 1.8 and 1.9 are locks and thread unsafe code in the Ruby implementation itself. So this is not something that will be immediately useful to most of you.
Regardless, this is the current trend in software. As the speed of individual cores is plateauing and the number of cores increasing, parallelizing your code is a must. But it looks, for now, that this feature won't be very useful quite yet.