SQL Server Object Concurrency
This is a perfectly acceptable way to implement pessimistic locking without affecting concurrency. 

You need to ensure, at the logical level, that whenever one session edits a record (which can translate to multiple rows in multiple tables at the physical level), no other session can modify any components of that logical record -- this is necessary to ensure consistency of your business data. To enable this you need to place some sort of a lock on all affected table rows. This, however, presents a problem in an interactive application, because humans are inherently slower than computers, they tend to look out of the window, make phone calls, go for a smoke or out for lunch before finishing the edit, which potentially leaves records locked for long time.

If you were to rely on physical U or X row locks in a pessimistic locking scenario, you sometimes might prevent other concurrent transactions from reading (or even reading past) the locked rows, thus affecting overall application performance. A safer, from the concurrency point of view, alternative is to logically mark certain rows as being edited by some session (by setting the InUse flag in your example) without placing physical locks on them. 

The cost of these extra updates to InUse in an interactive application is negligible, since, as we noted, the human component in it is still much slower.

This, of course, only works if all applications accessing the database know about and honour these logical locks.