If I understood everything correctly:
A transaction stores multiple actions. Transactions are stored in blocks. Every block producer has its turn (approx. 0.5 sec for this DPOS) to create a block and execute the corresponding transactions including their actions deterministically. If there would be concurrent write access of multiple block producers to the shared data, it would break consensus.
What could be a problem is, that you could access the data from between the time a block producer has created the block (where a write happened), but others did not yet mirrow the updates. Then you would have old data.
But it would not be a big deal, if you try to change the data with a new write based on the old values, because the transactions/actions would be invalidated by the block producers.
Please correct me if I am wrong or do miss something.
I reread the whitepaper. In fact for databases the access is serializable. This will likely be handled like in conventional DBMS.
To support parallel execution, each account can also define any number
of scopes within their database. The block producers will schedule
transaction in such a way that there is no conflict over memory access
to scopes and therefore they can be executed in parallel.
For the June 2018 release everything seems to be single threaded. For later releases there is this concept of cycles and shards:
Receiver and Notified Accounts (parallel)
I would recommend to reread the whitepaper as well.