On 16 October 2015 at 10:11, Savolainen, Petri (Nokia - FI/Espoo) < [email protected]> wrote:
> > > > > *From:* EXT Ola Liljedahl [mailto:[email protected]] > *Sent:* Thursday, October 15, 2015 10:55 PM > *To:* Savolainen, Petri (Nokia - FI/Espoo) > *Cc:* LNG ODP Mailman List > *Subject:* Re: [lng-odp] [API-NEXT PATCH 6/6] api: atomic: added 32 bit > acquire and release > > > > On 15 October 2015 at 10:45, Petri Savolainen <[email protected]> > wrote: > > Added 32 bit acquire load/cas and release store/add/sub calls. > > You only have cas_acquire. Don't you see a need for cas_release? I use > that in one lockless design. > > > > I see the beginning of a combinatorial explosion here. Why not just expose > the atomic operations that take the memory ordering as a parameter? > > > > -- Ola > > > > I’m trying to limit the combinatory explosion here by defining only those > combinations that are mostly used, which are: load – acquire and store – > release, right? > And then you have e.g. cas_acquire. By specifying the ordering as part of the function name, you will have to add a lot of new calls (e.g. cas_release which I use) in the future. A memory order parameter would open the can of all kind of combinations > that would then need more documentation telling which ones are actually > legal, useful or high/low performance. > Anyone using these calls need to understand memory consistency. Thats a separate subject, not invented by ODP. We don't have to provide a complete documentation of memory consistency. Other API's and concepts in ODP are ODP specific so we need complete documentation. But atomics and memory consistency is a different case, there's nothing ODP specific about it. > > Cas_release is kind of odd combination – try to release something with cas > that you own already? > It's not odd at all. The release ordering just makes sure that the pointer I (conditionally) swap in can be safely dereferenced by someone which acquires (load_acquire or cas_acquire) the same pointer. I cannot use store_release in this specific case. Acquire and release must pair, using a relaxed cas does not work (my prior writes, e.g. by dereferencing the pointer, are not guaranteed to by observable). We can leave it out from API, if it’s a rarely needed/used combination. > I think we need to add e.g. cas_release to the API when it is needed (not necessarily now) because it is a valid combination even though it might not be very frequently used. It cannot be replaced with something else. It’s easier to add later combinations that have a generally accepted use > case, than remove those that are not really needed or useful. > > > > -Petri > > > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
