I think it is thread safe.. sort of, as now it supports MARS:

From http://blogs.msdn.com/angelsb/archive/2004/07/15/184479.aspx:
"
Multiple Active Result Sets per connection (MARS):

I don't really believe this feature will be the winner of the PTBGM, but it
is definitely a contender. When connecting with SqlClient to Sql Server 2005
(or with Oledb and the next release of the network libraries) we will now
allow multiple active result sets per connection. In ado.net this mostly
means that you will now be able to open multiple datareaders per connection
as long as you use a separate command for each. The main scenario for this
feature would be being able to modify the database as you process a
datareader, it also enables running queries inside of the same transaction
context and _can_ have a performance benefit in very specific scenarios
where the cost of more connections (about 40k memory per connection) becomes
a concern. There are a number of ways in which "things can go wrong" T
however. Forgetting to close a datareader will now stop you from committing
a transaction, modifying the state of the connection can give you unexpected
results, reading and writing inside of a transaction context may isolate the
reader from the changes and writer writer conflicts are non deterministic.
Overall fairly minor and contrived concerns, my personal biggest problem
with this feature however is that it is hard to squeeze real performance
gains out of it, and easy to write hard to maintain code to try it. There
are performance implications to using MARS across the board. On the client
we run into an issue where creating a new batch is not free, we kind of work
around this issue by pooling mars commands but still expensive if you don't
used the pooled functionality. On the network layer there is a cost
associated with multiplexing the tds buffer, opening too many batches can be
more expensive than opening another connection. On the server all MARS
batches run in the same scope, worst case scenario your queries will end up
running in the order received.

I really like the current way to use ado.net, open a new connection in each
thread and rely on pooling to get performance and ease of development. It is
tempting with the advent of mars to switch this model to one where we open
one connection and rely on using a different command in each thread, I would
not recommend it. Misusing (IMO) MARS to try to get additional performance
has the potential of making your code look like a bowl of spaghetti for very
unclear performance benefits.

My opinion: Don't try to use MARS and threading to improve performance.

"

The last paragraph seems to say that, yes, it is thread safe, but please do
not use it.
And I do agree. Connection pooling is way more efficient.

Laura