Do isolation levels only apply to SELECTS and not UPDATES? Scenario that might demonstrate different behavior for SELECTS depending on the isolation level:

1) 0:00 Thread A runs a query that returns 1000 rows that takes 5 minutes to complete
2) 0:02 Thread B runs a query that returns the same 1000 rows
3) 0:05 Thread A updates the last 1 rows in this result set and commits them
4) 0:07 Thread B's query returns* 


Depending on the isolation level, the result set in #4 will either contain Thread A's changes or it won't. Is the same true for UPDATES?

The following is an example scenario:

Thread A: UPDATE... set version=6 ... WHERE primary_key = 1234 AND version = 5
Thread B: UPDATE... set version=6 ... WHERE primary_key = 1234 AND version = 5


If both Thread A and Thread B enter their transactions at the same time, and Thread B performs its update after Thread A, will Thread B's update fail to update any rows or will it "see" the record with version 5 and therefore overwrite what Thread A wrote?

Does it depend on the database? e.g. Oracle vs MySql vs PostgreSQL?
In MS SQL Server I can say that it depends on your isolation level.  If you set it more similar to Oracle by making it 'snapshot isolation', the last row that thread A is trying to update will have the 'before' value copied to tempdb, and all reads will read that while it is being updated via a row lock.  

If you have the default isolation level of read committed, it will lock that row (or in some cases page) blocking your reader from that particular row or page while it updates it.  This is unless you specify SET ISOLATION LEVEL READ UNCOMMITTED or put a (NoLock) hint on the FROM clause of the query, thus allowing dirty reads.

It all has to do with the Isolation level in ACID, and it's the only ACID property that you have control over in MS SQL Server.