mtak- / lstm Goto Github PK

There's substantial overhead in maintaining the read/write sets. For read only transactions, maintaining the read/write sets is totally unnecessary AFAICT. This means lookups in the write set can be avoided, as well as adding elements to the read set.

read_write transactions should be allowed to call read_only transactions. This implies a branch is required to decide if the transaction really is in read_only mode or in read_write mode (in which case checking the write set and maintaining the read set cannot be avoided).

There must be a way to avoid this branch in known read_write transactions.

Currently, users have access to the low level RCU primitives through thread_data if desired. It would be convenient to add some wrappers similar to read_write to handle the bookkeeping for the user.

This will need some experimentation if STM and RCU are to play nicely together. In order to publish data in a way that works well with the STM side of things, vars will need to have some seqlock style API. I'm not even sure if STM should be allowed to call RCU code.

transaction is more or less a handle to thread_data with some additional info:

• transaction_domain* domain_ which never gets mutated (and in fact cannot be mutated)
• gp_t read_version which can only be mutated from outside the rootmost closure passed into a read_write block; moreover, read_version is really just a non-atomic version of the grace period in thread_data. It's possible this variable should be nuked altogether (benchmark).

This means transaction could be passed around by value avoiding the extra indirection. If we do that, the name of the class maybe should change to reflect that it's a handle/context and users are free to copy it about, though assigning it doesn't really make sense (it's kind of a const handle?).