Hi Thomas,
I feel that we should group the RC_BUSY cases.
My suggestion : >>>
A node MAY support concurrent 6P Transactions from different neighbors. In
this case the cells involved in the ongoing 6P transaction MUST be locked until
the transaction finishes. For example, in Figure 1, nod
All,
We have reached a consensus, in summary:
- a 6P transaction is not infinitely fast, we need to guarantee atomicity
of the cell reservation process
- In case of concurrent transactions involving the same cells on a
particular node, that node need to be able to "lock" access to those cells
duri
Thank you Xavi for posting these details to the public ML.
On Fri, May 13, 2016 at 5:48 PM, Xavier Vilajosana <
xvilajos...@eecs.berkeley.edu> wrote:
> Dear all,
>
> following the indications of Suresh raised today at the conf call, please
> see the discussion thread that followed from Charlie's
