On 12.04.2017 14:05, Joe Savage wrote: > On 12/04/17 11:32, Maxim Uvarov wrote: >> On 12.04.2017 13:15, Joe Savage wrote: >>>>>> The problem is that when we discussed this patch on ODP call people very >>>>>> worry about having 128bit instructions in ODP examples. At least Petri >>>>>> and Barry asked if it would be possible to rewrite that with 64 bit >>>>>> instructions? Some compilers might not support 128 bits and we need to >>>>>> test it more. >>>>> >>>>> On 32-bit platforms, it already does use 64-bit atomics. In general, >>>>> though, >>>>> the example hinges around having atomics that are twice the pointer size. >>>>> We've actually discussed this on the list already in the thread "32-bit >>>>> support in examples". Even if lock-free implementations can't be used, >>>>> compilers can (and frequently do?) provide a lock-based compare exchange >>>>> operation. >>>> >>>> Any progress on this? >>> >>> This is getting mildly ridiculous now — it's nearing three months since I >>> initially submitted this simple example patch, and there's still no end in >>> sight! Maxim: any status updates? >>> >> >> Dmitry wanted to write some big review for that patch. But I do not see >> anything here. People commented on 128 bit instructions in examples and >> nobody set their review-by. I will rise question about your patch one >> more time on arch call. I can not include things where we did not get >> common agreement. I do not see anything bad with this patch but we need >> account all existence odp platforms.
I'm sorry for the delay. Was quite under a pile of IPsec stuff... I'm quite not happy about intermixture of arch-dependent and arch-specific stuff in headers. Would it be possible to split arch-specific implementation details to per-arch headers (one for AArch64, one for older ARM and one generic) and include proper header based on the $(ARCH_DIR)? It would be especially nice to have such header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just atomic_strong_cas_dblptr() ). > > I totally appreciate that some form of agreement needs to be reached before a > given patch can be merged, but I don't think that leaving me in the dark about > the status of such issues is a particularly good way to run things. (This is > hardly a healthy process for encouraging contributions.) > > As I mentioned in the previous discussions (to no response), lock-based > compare exchange implementations are perfectly acceptable, and thus there > should not be any earth shattering compatibility issues here. > -- With best wishes Dmitry
