Your query does make sense, but because you are new, you didn't realize this is not a deadlock situation, it is a blocking situation. In order for a deadlock to occur two different resourses have to contend for resources that the other has achieved. In this example the first query will complete and stop, the second query will never complete until the resource is released which never happens.

You can get a deadlock by creating a second table with the same resouces and data loaded into it. In the first query use the transaction and update query originally used, run it. In the second query begin the transaction and then update BOTH tables, but first update the SECOND table!

You'll get a time indicater and the query won't stop.

Go back to the second window, clear out your commands and just update the second table and run it.

Both queries will stop almost simultaniously, one indicating it is finished without error, the second will finish with a deadlock message. I have some idea the first query will be the deadlock victim, but that isn't a sure thing. (The second query has spent some time being blocked so it's cost is climbing.)

If you run the lock query now, you'll only see the (successful) locks on both tables in the surviving spid still exist.