Update statements with set transaction isolation level read uncommitted

If I have a stored procedure with set transaction isolation level read uncommitted, will it affect update statements?

I know that you should not use with (nolock) on update/delete statements, and this does pretty much the same thing but not sure if SQL ignores it on update statements in the procedure or if I should be careful not to use it if there are update statements.

EDIT:

Sorry for the confusion. I'm not trying to figure out what the effect of using this type of locking on manipulation statements would be or whether it's a good idea. In fact I do NOT want to use this kind of locking on manipulation statements, and so my question is whether putting "set transaction ..." at the top of my stored proc is ever going to be honored by update/delete statements or whether it will be ignored. My hope is that it is just ignored.

I am fully aware of the effects (with its pros and cons) it will have on select statements.

If I have a stored procedure with set transaction isolation level read
uncommitted, will it affect update statements?

Read uncommitted allows dirty reads. An X lock will be taken on the row or higher level (in the data page or index) before it is made dirty. Rows accessed directly by the query when locating a row to update will take a U lock and be blocked.

However it is still possible for an Update to be affected by the isolation level.

Connection 1

CREATE TABLE T1
(
X INT NULL,
Y INT NULL
);

INSERT INTO T1 DEFAULT VALUES;

BEGIN TRAN
UPDATE T1 SET X = 100;    

WAITFOR DELAY '00:00:10'

ROLLBACK;

Connection 2 (run this within 10 seconds of firing off connection 1)

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

UPDATE T1
SET    Y = (SELECT SUM(X)
            FROM   T1);

SELECT *
FROM   T1;

Result

The read operation read the uncommitted value and the final result was used in the UPDATE even though the 100 that was read was eventually rolled back.

StackExchange Database Administrators Q#147624, answer score: 5