Re: Portable memory barrier?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 11/05/2017 00:56, Jere wrote:
> On Wednesday, May 10, 2017 at 1:26:00 AM UTC-4, J-P. Rosen wrote:
>> Le 10/05/2017 à 02:51, Jere a écrit :
>>> Is there a method besides Atomic?  If I am implementing a generic FIFO (lock
>>> free) and the FIFO elements are complex data types that may not be able to be
>>> atomic, do I have any other options or are protected objects my only way out?
>>
>> Protected objects, or for a lower level, Synchronous_Task_Control. I
>> know that you want lock free algorithms, but out of curiosity, did you
>> measure the cost of locking algorithms? IOW, is all of this worth the
>> trouble?

> I wasn't necessarily aiming for a specific speed/cost.  I know I can easily
> find a standard task safe container and use that and it might be faster (or at
> least fast enough) on various platforms.  This is more for a different option
> from the normal.  It might be faster on some platforms or slower, but it is
> mostly meant to be a tool in toolkit.

One issue is granularity of locking. If container operation is not 
instant, and that depends on the nature of the elements, doing that on 
the context of protected action is a bad idea. The solution for 
protected objects is of using a mutex to guard the operation outside the 
protected action. The cost is two protected actions per operation 
instead of one.

A lock-free implementation does not have this issue. Note that whether 
the FIFO index is atomic or in a protected object is no matter. In both 
cases the method is lock-free.

So, Jere, when you become ARG (:-)), please, push for requirement to 
support Atomic for all scalar objects. If the machine lacks 
corresponding instructions the compiler must fall back to a protected 
object. And conversely, if there is a strong case that using a protected 
action might be more efficient than machine's atomic access 
instructions, the compiler should use the former.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de