Hi, >>I'm not sure this is really about the cost. I rather have concerns >> about contention and conflicts in the distributed case. > >That's a part of the cost I was thinking of. This clearly is a >significant design decision to make, which is why I'd hope to see some >actual numbers to back us (it would have been great if the existing >prototypes had already provided such detail).
I agree, numbers would be good. I felt a negative (sometimes hostile) attitude towards benchmarks so far. I fear no matter what the numbers are, they would be declined on the basis of that they are not relevant. >Alternatively, we could >leave the orderability issue undefined for now, and revisit the >decision once we have a better idea of what works and what doesn't. Yes, I would leave it undefined. I don't think it will or should hold us up. >I think it would be useful to tie orderability and >SNSs together, as any code that implements SNSs should fairly easily >be able to give us orderability as well. I don't think that they are (or should be) tied together that much. >Thus I think it would be a >good solution to implement both either below or above the MK level. >Splitting the features across the MK line doesn't seem that useful. I view them as distinct features actually. Regards, Thomas
