Deadlock occurred on same table with DELETE and SELECT statements

I received a deadlock notification e-mail today indicating that a deadlock had occurred between a DELETE and SELECT statement on the same table. After looking at the deadlock information, reviewing the index and searching around the forums, I'm wondering if it would have been related to how indexes on the table are setup. Rather than setting the isolation level to read uncommitted on the SELECT statement, I'm looking for a cause of why this happened and how to avoid it in the future instead of throwing a bandage on it. Below are the 2 statements (shortened):

DELETE FROM Table WHERE Col1 = @P1 AND Col2 = @P2

SELECT COL1, ..., Col4 FROM Table WHERE Col1 = @P1 AND Col2 = @P2

I'm not sure of the values of the 2 parameters so they could either been the same or different. I have a PK non-clustered index on Col1 as well as a unique non-clustered index composed of Col1 and Col2.

I've pulled this from the deadlock information and substituted in my column and table names:

resource-list
ridlock fileid=3 pageid=121596 dbid=53 objectname=mydb.dbo.Table id=lock3ea41e00 mode=X associatedObjectId=72057596270477312
owner-list
owner id=process2f4f2e8 mode=X
waiter-list
waiter id=process34a02f8 mode=S requestType=wait
keylock hobtid=72057596584132608 dbid=53 objectname=mydb.dbo.Table indexname=Unq_Table_Col1Col2 id=lock534bc800 mode=U associatedObjectId=72057596584132608
owner-list
owner id=process34a02f8 mode=S
waiter-list
waiter id=process2f4f2e8 mode=X requestType=convert

Unfortunately I do not have full control over the table and index structure so I can only make requests on what I would like to have changed. In order to do that, I need to be a bit educated on how the indexes are being utilized, and if they can be used more efficiently, why and how?