In salesforce, it's not like another thread owned by you is accessing the records in another database session.
As all the operations that occur on the records in scope are in the same context, your execution, Salesforce knows that
so it doesn't cause a deadlock.
Salesforce executions are single threaded and follow a strict order. As the operations happen in series they don't contend with other operations caused by the same execution, as the same set of records are being pushed through the execution.
There's an explanation of the order here, and it's quoted below.
On the server, Salesforce:
- Loads the original record from the database or initializes the record for an upsert statement.
- Loads the new record field values from the request and overwrites
the old values. If the request came from a standard UI edit page,
Salesforce runs system validation to check the record for:
Compliance with layout-specific rules Required values at the layout
level and field-definition level Valid field formats Maximum field
length Salesforce doesn't perform system validation in this step
when the request comes from other sources, such as an Apex
application or a SOAP API call. Salesforce runs user-defined
validation rules if multiline items were created, such as quote line
items and opportunity line items.
- Executes all before triggers.
- Runs most system validation steps again, such as verifying that all
required fields have a non-null value, and runs any user-defined
validation rules. The only system validation that Salesforce doesn't
run a second time (when the request comes from a standard UI edit
page) is the enforcement of layout-specific rules.
- Executes duplicate rules. If the duplicate rule identifies the
record as a duplicate and uses the block action, the record is not
saved and no further steps, such as after triggers and workflow
rules, are taken.
- Saves the record to the database, but doesn't commit yet.
- Executes all after triggers.
- Executes assignment rules.
- Executes auto-response rules.
- Executes workflow rules.
- If there are workflow field updates, updates the record again.
- If the record was updated with workflow field updates, fires before
update triggers and after update triggers one more time (and only
one more time), in addition to standard validations. Custom
validation rules and duplicate rules are not run again.
- Executes processes.
If there are workflow flow triggers, executes the flows.
The Process Builder has superseded flow trigger workflow actions,
formerly available in a pilot program. Organizations that are using
flow trigger workflow actions can continue to create and edit them,
but flow trigger workflow actions aren’t available for new
organizations. For information on enabling the Process Builder in
your organization, contact Salesforce.
- Executes escalation rules.
- Executes entitlement rules.
- If the record contains a roll-up summary field or is part of a
cross-object workflow, performs calculations and updates the
roll-up summary field in the parent record. Parent record goes
through save procedure.
- If the parent record is updated, and a grandparent record contains
a roll-up summary field or is part of a cross-object workflow,
performs calculations and updates the roll-up summary field in the
grandparent record. Grandparent record goes through save procedure.
- Executes Criteria Based Sharing evaluation.
- Commits all DML operations to the database.
- Executes post-commit logic, such as sending email.