I had to kill a user Query today since it was causing blocking. The user did just what was advised, use NOLOCK.. yet the user’s Query had to be killed because of this.
Where you would expect that writers don’t get blocked by readers using dirty reads, this is not the case when the writer executes a TRUNCATE TABLE command. This is because a truncate is regarded as a DDL operation (not DML). More technically, a select statement holds a sch-s(schema stability) lock (even using isolation level read uncommitted) on the object where a truncate will hold a sch-m(schema modification) lock on the object and these locks are not compatible.