All right. I ran a test using an XEvent session to get the locks acquired by DBCC CHECK_IDENT with a RESEED. The important locks acquired are a SCH-M (Schema Modification) on the target table, an IX (intent Exclusive) on syscolpars, and an X (Exclusive) lock on a key in syscolpars. According to the lock compatability matrix found in BOL here, the SCH-M lock is incompatible with S(hared) locks so a read should block the reseed.
It was pretty easy to duplicate the issue just by having a long running query take a shared lock on the table.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question