How to avoid shared locks when validating foreign keys?

Question

I have a table with a FK and I want to update a row in that table without being blocked by another transaction which is updating the parent row at the same time. Here is an example:
CREATE TABLE dbo.ParentTable
PARENT_ID int NOT NULL,
VALUE varchar(128) NULL,
CONSTRAINT PK_ParentTable PRIMARY KEY (PARENT_ID)
GO
CREATE TABLE dbo.ChildTable
CHILD_ID int NOT NULL,
PARENT_ID INT NULL,
VALUE varchar(128) NULL,
CONSTRAINT PK_ChildTable PRIMARY KEY (CHILD_ID),
CONSTRAINT FK_ChildTable__ParentTable FOREIGN KEY (PARENT_ID)
REFERENCES dbo.ParentTable (PARENT_ID)
GO
INSERT INTO ParentTable(PARENT_ID, VALUE)
VALUES (1, 'Some value');
INSERT INTO ChildTable(CHILD_ID, PARENT_ID, VALUE)
VALUES (1, 1, 'Some value');
GO
Now I have 2 transactions running at the same time:
The first transaction:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;BEGIN TRAN
UPDATE ParentTable
SET VALUE = 'Test'
WHERE PARENT_ID = 1;
The second transaction:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;BEGIN TRAN
UPDATE ChildTable
SET VALUE = 'Test',
PARENT_ID = 1
WHERE CHILD_ID = 1;
If 'UPDATE ParentTable' statement runs a bit earlier, then 'UPDATE ChildTable' statement is blocked untill the first transaction is committed or rollbacked. It happens because SQL Server acquires shared locks when validating foreign keys, even
if the transaction is using read uncommitted, read committed snapshot (read committed using row versioning) or snapshot isolation level. I cannot see why change in the ParentTable.VALUE should prevent me from updating ChildTable. Please note that ParentTable.PARENT_ID
is not changed by the first transaction, which means that from FK's point of view whatevere is set to the ParentTable.VALUE is never a problem for referential integrity. So, such blocking behavior seems to me not logical. Furthermore, it contradicts to the
MSDN:
Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the
current transaction from reading rows that have been modified but not committed by other transactions. 
Does anybody know how to workaround the issue? In other words, are there any tricks to avoid shared locks when validating foreign keys? (Disabling FK is not an option.) Thank you.
Alexey

Answer 1

If you change the primary key of the parent table to be nonclustered, there is no blocking.
Indeed, when I update ParentTable.VALUE, then:
in case of PK_ParentTable is clustered, a particular row in the clustered index is locked (request_mode:X, resource_type: KEY)
in case of PK_ParentTable is non-clustered, a particular physical row in the heap is locked (request_mode:X, resource_type: RID).
and when I update ChildTable.PARENT_ID, then:
in case of PK_ParentTable is clustered, this index is used to verify referential integrity:
in case of PK_ParentTable is non-clustered, again this index is used to verify referential integrity, but this time it is not locked:
It is important to note that in both cases SQL Server acquires shared locks when validating foreign keys. The principal difference is that in case of clustered PK_ParentTable the request is blocked, while for non-clustered index it is granted.
Thank you, Erland for the idea and explanations.
The only thing that upsets me is that this solution cannot be applied, because I don't want to convert PK_ParentTable from clustered to non-clustered just to avoid blocking issues. It is a pity that SQL Server is not smart enough to realize that:
ParentTable.PARENT_ID is not changed and, as a result, should not be locked
ChildTable.PARENT_ID is not actually changed either (old value in my example is 1 and the new value is also 1) and, as a result, there is no need at all for validating the foreign key.
In fact, the problem I described is just a tip of the iceberg. The real challenge is that I have deadlocks because of the FK validation. In reality, the first transaction has an additional statement which updates ChildTable:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
BEGIN TRAN
UPDATE ParentTable
SET VALUE = 'Test'
WHERE PARENT_ID = 1;
UPDATE ChildTable
SET VALUE = 'Test'
WHERE PARENT_ID = 1;
The result is famous message:
Msg 1205, Level 13, State 51, Line xx
Transaction (Process ID xx) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
I know that if I change the order of the two statements, it will solve the deadlock issue. But let's imagine I cannot do it. What are the other options?
Alexey