Re: What's the connection between objects and threads?

That's not really the point (although it certainly would be in
some applications). The point is that this idea was put forward
many, many years ago; it works well when you're dealing with
simple objects, like int's, but it doesn't work when you start
dealing with sets of objects grouped into transactions.
Ensuring transactional integrity in a multi-threaded
environment, without deadlocks, still requires manually managing
locking and unlocking---even scoped locking doesn't really work
here. (You can implement transactions with scoped locking, but
only if you only handle one transaction at a time. In which
case, there's really no point in being multithreaded.)