Can a clustered index with low cardinality cause deadlocks? I'm looking at a deadlock, which happens when two processes execute an UPDATE statement on the same table. Both transactions are implicit, meaning that they span only the current statement only, which in turn means that locks I'm seeing are not a carry over from a prior statement.

There are two locks and two processes involved in the deadlock. One of the two locks is a page lock in the table (One process has update lock the other one wants Intent Exclusive lock) and the second one is the key lock on the table clustered index (one process has Exclusive lock and the other wants the update lock).

Now, the fields being updated in the both UPDATE statements are not a part of the clustered index.

Still, I'm wondering can the fact that this clustered index has tonnes of duplicate values contribute to the deadlock?

I'm sorry for not posting the deadlock trace, the update statements, the definition of the table and of the index, there is too much to obfuscate.

My question is not how to solve my deadlock, my question is about effect of low cardinality clustered index on probability of deadlocks in principle.
One of the two locks is a page lock in the table (One process has
  update lock the other one wants Intent Exclusive lock)


This mean that the table is big enough so that the engine has decided to use page granularity locks in order to discover the rows to be updated. Then as it 'drills' in' to actually apply the update to the rows, the deadlock occurs because the two updates both located the row-to-update on the same page. You could force rowlock, or you could disable page locks on the table, but the real problem is that it looks like the WHERE clause of the UPDATE is non-sARG-able.