> Admittedly this makes reads of the whole file more costly, so one has to be careful about the block size.

Maybe? You're probably locking each block at a time in the buffer cache during reads anyway.

N.B.: in V7 (and 32V), inodes are locked identically for both writes and reads[1],

    if((ip->i_mode&(IFCHR&IFBLK)) == 0)
      plock(ip);
    if(mode == FREAD)
      readi(ip);
    else
      writei(ip);
    if((ip->i_mode&(IFCHR&IFBLK)) == 0)
      prele(ip);

I imagine a more serious bottleneck to heavy random-access concurrency on files large enough to be worth splitting would be disk performance, as there's not likely to be a lot of room in physical RAM on a busy PDP-11 or VAX-11/7xx free for buffer caching.

And for smaller files able to be serviced entirely from cache, I don't imagine lock contention as a serious issue on a single-processor system like the ones that ran V7/32V.

Average seek time / rotational latency (years estimated by manual copyright):

RL02 (1978): 55 ms / 12.5 ms

RK07 (1978): 36.5 ms / 12.5 ms

RA81 (1982): 28 ms / 8.3 ms

RA92 (1989): 16 ms / 8.3 ms

Note that the RL02 (and V7) and RA92 mentioned in the article are separated by about a decade.

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...