LEVELDB-Concurrent Write processing

In concurrent writes, Leveldb cleverly uses a time window for batch writing, which is worth reading:

Status dbimpl::write (const writeoptions& options, writebatch* my_batch) {//A begin Writer W (&mutex_);  W.batch = My_batch;  W.sync = Options.sync;  W.done = false;  A End//B begin Mutexlock L (&mutex_);  Writers_.push_back (&W);  while (!w.done && &w! = Writers_.front ()) {w.cv.wait ();  } if (W.done) {return w.status;  }//B end//may temporarily unlock and wait.  Status status = Makeroomforwrite (My_batch = = NULL);  uint64_t last_sequence = Versions_->lastsequence ();  writer* Last_writer = &w; if (Status.ok () && my_batch! = NULL) {//null batch is for compactions writebatch* updates = Buildbatchgroup (    &last_writer);    Writebatchinternal::setsequence (Updates, last_sequence + 1);    Last_sequence + = Writebatchinternal::count (updates);  ADD to log and apply to memtable. We can release the lock//during this phase since &w are currently responsible for logging//and protects again St Concurrent LoggERS and Concurrent writes//into MEM_. {mutex_.      Unlock ();      Status = Log_->addrecord (writebatchinternal::contents (Updates));      BOOL Sync_error = false;        if (Status.ok () && options.sync) {status = Logfile_->sync ();        if (!status.ok ()) {sync_error = true;      }} if (Status.ok ()) {status = Writebatchinternal::insertinto (updates, mem_); } mutex_.      Lock (); if (sync_error) {//The state of the log file is indeterminate:the log record we//just added        Not show on when the DB is re-opened.        So we force the DB into a mode where all writes fail.      Recordbackgrounderror (status);    }} if (updates = = Tmp_batch_) tmp_batch_->clear ();  Versions_->setlastsequence (last_sequence);    } while (true) {writer*-ready = Writers_.front ();    Writers_.pop_front ();      if (ready! = &w) {ready->status = status;  Ready->done = true;    READY->CV.    Signal ();  } if (ready = = Last_writer) break; }//Notify new head of write queue if (!writers_.empty ()) {Writers_.front ()->CV.  Signal (); } return status;

Suppose there are simultaneous W1, W2, W3, W4, W5, W6 concurrent request writes.

Part B code allows the W1 to compete with the mutex resource to acquire the lock. W1 adds the data it wants to write to the Writers_ queue, when the queue has only one W1, so it goes smoothly buildbatchgroup . When the Mutex_ mutex is released when running to 34 rows, Mutex_ can be released here because other writes do not meet the team's first condition and will not enter the log and memtable write phases. At this time (W2, W3, W4, W5, W6) will compete for the lock, because the B code does not meet the first condition of the team, are waiting for and release the lock. Thereby the queue may be as (W3, W5, W2, W4).

The log write and memtable write are then W1. When W1 completes log and Memtable writes and enters 46 lines of code, the mutex_ is locked again, and the queue in the B-segment code is not modified because the lock is not acquired.

The next 59 lines start, W1 by pop out, because of reader==w, and Ready==last_writer, so directly to 71 lines of code, wake up at this time in the team's first W3.

W3 wake up, found himself is the first team, can smoothly enter buildbatchgroup , in the function, traversed all the current queue elements, form an update batch, will W3, W5, W2, W4 merged into a batch. and Last_ Writer is set to the last element at the end of the queue after the w4,34 line code runs, because the lock resources are freed, the queues may change with dbimpl::write calls, such as the queue condition (W3, W5, W2, W4, W6, W9, W8).

35-45 lines of code will W3, W5, W2, W4 the entire batch to log and memtable. To 65 rows, respectively, to W5, W2, W4 conducted a cond signal. When the W4 = = Lastwriter is determined, exit the loop. 72 lines of the first W6 wake up, so that the above-mentioned steps to go on.

This creates a mechanism for multiple concurrent write merges to write log and memtable to a batch.

　　

LEVELDB-Concurrent Write processing