How to concurrency will be handled in this case?
The processes can theoretically work concurrently on different records, row locks are obtained as needed not in advance. However, in this case they are bound to run into each other sooner or later. If both have locked at least one record when that happens they will deadlock (both wait for the other to release a lock that it needs) and the database will kill one. Alternatively one will get the locks first and the other will wait until it commits; then it will update the records again.

In other words you can never end up with a scenario where A has updated some records and B some records. A will either update all or fail (due to deadlock/timeout) and B will also either update all or fail.

EDIT: if you do want to share load in this way you can get that effect using a select ... for update skip locked. Then locked records are simply ignored and the sessions can split the work, often quite useful in polling scenarios. Or use a parallel hint for the update and make a single session run in parallel.