Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  05 Dec 2018, Konstantin Olchanski, Info, Partial refactoring of ODB code 
    Reply  11 Dec 2018, Stefan Ritt, Info, Partial refactoring of ODB code 
       Reply  26 Dec 2018, Konstantin Olchanski, Info, Partial refactoring of ODB code 
          Reply  27 Dec 2018, Stefan Ritt, Info, Partial refactoring of ODB code 
Message ID: 1419     Entry time: 26 Dec 2018     In reply to: 1414     Reply to this: 1423
Author: Konstantin Olchanski 
Topic: Info 
Subject: Partial refactoring of ODB code 
> One additional comment: In the 90's when I developed this code, locking was expensive.
> Now the world has changed, we can do almost a million locks a second.

I am not sure this is quite true. The CPU can execute 3000 million operations per second (3GHz CPU, assuming 1 op/Hz),
so 1 lock operation is worth 3000 normal operations. Of course cache misses and branch mispredictions mess up
this simple arithmetic...

But I think cost of mutex lock/unlock can be easily measured. (hmm... now I am curious).

Bigger question is architectural, nested/recursive locks is definitely a bad thing to do (not just my opinion).

But closer to home, as I implemented "write protected" ODB, lock/unlock suddenly has to do MMU operations
(map unmap memory) and this is *very* expensive.

Also as we start doing more multithreading, lock contention is becoming a problem, and the standard solution
is to implement read-locks and write-locks. (everybody holding a read-lock can read ODB at the same time
without waiting).

So, moving in the direction of separate read and write locks and write-protected (and/or read-protected) ODB shared memory,
all points in the direction of reworking of ODB locks in the direction of removing the need for nested/recursive locks.

I think me and Stefan are in agreement here.

K.O.
ELOG V3.1.4-2e1708b5