0

I'm reading through the OpenCL 2.0 Specification because I'd like to learn more about synchronization methods. More specifically I'm currently reading through section 3.3.5 Memory model: Overview of Atomic and Fence operations, where I currently struggle to understand fences.

I'll quote the relevant bits with my questions:

The OpenCL 2.0 specification defines a number of synchronization operations that are used to define memory order constraints in a program. They play a special role in controlling how memory operations in one unit of execution (such as work-items or, when using SVM a host thread) are made visible to another. There are two types of synchronization operations in OpenCL; atomic operations and fence.

This is clear... it's just defining the synchronization mechanism provided by OpenCL.

Atomic operations are indivisible.They either occur completely or not at all. These operations are used to order memory operations between units of execution and hence they are parameterized with the memory_order and memory_scope parameters defined by the OpenCL memory consistency model.The atomic operations for the OpenCL C kernel programming language are similar to the corresponding operations defined by the C11 standard.

This is clear, it's just defining what an Atomic operation is, namely an operation which is fully executed or not executed at all per cycle.

The OpenCL 2.0 atomic operations apply to variables of an atomic type (a subset of those in the C11 standard) including atomic versions of the int, uint, long, ulong, float, double, half, intptr_t, uintptr_t, size_t, and ptrdiff_t types. However, support for some of these atomic types depends on support for the corresponding regular types.

So it sounds to me that in order to execute an atomic operation we need a variable, and therefore a memory address. The following is the bit that confused me

An atomic operation on one or more memory locations is either an acquire operation, a release operation, or both an acquire and release operation. An atomic operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which do not have synchronization properties, and atomic read-modify-write operations, which have special characteristics. [C11 standard, Section 5.1.2.4, paragraph 5, modified]

In this last paragraph there's the specific bit

... An atomic operation without an associated memory location is a fence ...

But how is this possible since any atomic is applied to certain variables?

talonmies
  • 70,661
  • 34
  • 192
  • 269
user8469759
  • 2,522
  • 6
  • 26
  • 50
  • https://stackoverflow.com/a/52196874/681865 -- like what you quote, atomic just means indivisible. It is perfectly possible to have atomic operations which are not atomic *memory* operations – talonmies Jan 06 '20 at 12:16
  • @talonmies But the specification it's specifically saying *An atomic without... is a fence*, according to this sentence a fence is a specific type of atomic (in the OpenCL language at least). – user8469759 Jan 06 '20 at 12:19
  • Why "but"? There is no contradiction. Fences order the memory operations of a work item and guarantee their visibility at a particular programmer defined scope. Atomic memory operations order the operations on a given memory address and guarantee their visibility at a particular programmer defined scope – talonmies Jan 06 '20 at 12:24
  • So the hierarchy is *atomic operations* which can be both *atomic memory operations* and *fences* if the *atomic* is applied to a memory location then the atomic is an *atomic memory operation* otherwise is a *fence*, is this what you're saying? – user8469759 Jan 06 '20 at 12:29
  • I suppose you could look at it that way, although I don't understand why the the semantics of this are so important to you. The general rule is that if you can't understand what a fence operation is, you almost certain will never need to use one – talonmies Jan 06 '20 at 12:43
  • Because if I read through the openCL specification and documentation I want to know what I'm reading about. The link you shared in your first comment isn't specific to openCL, but my intuition agrees with it. – user8469759 Jan 06 '20 at 12:45

0 Answers0