I'm happy to see good answers already posted here. Jim Thompson is right. Multiple threads executing in parallel is the answer. As far as what is happening, I see a locking wait type which jives with the query you shared because it is using a query hint demanding locks. That query hint tells the database instance to use locks until the transaction is complete. Add to this that I think the lock type I see there (it's a little blurred) is LCK_M_U, which is a wait for an update lock. So you might look at the whole stack of SQL that is running with concern that you wrap up those transactions quickly to release the locks. Because I don't have the whole stack of SQL here, it's hard for me to give more details but cursors are always concerning for SQL Server because they are generally slower operations. Database engines excel with set based operations and cursors are iterative operations (loop constructs). The larger the loops, the longer they take. They don't scale well.
UPDLOCK
Specifies that update locks are to be taken and held until the transaction completes. UPDLOCK takes update locks for read operations only at the row-level or page-level. If UPDLOCK is combined with TABLOCK, or a table-level lock is taken for some other reason, an exclusive (X) lock will be taken instead.
When UPDLOCK is specified, the READCOMMITTED and READCOMMITTEDLOCK isolation level hints are ignored. For example, if the isolation level of the session is set to SERIALIZABLE and a query specifies (UPDLOCK, READCOMMITTED), the READCOMMITTED hint is ignored and the transaction is run using the SERIALIZABLE isolation level.