fence (in program order) must be committed to the memory hierarchy before any operation after the fence. Then, for data to be transferred from one thread to another it is not necessary to be atomic anymore. I.e., it is sufficient that (1) the signaling variable is atomic, and that (2) all write operations are committed to the memory hierarchy before setting the signaling variable. On the receiver’s side, it must be ensured that (3) the signaling variable is read atomically, and that (4) memory loads for the data occur after reading the signaling variable (Listing \[genRA\] provides an example.)

In addition to [synchronized]{} variables, [synchronized]{} types and attribute are convenient means for enhancing the usefulness of [synchronized]{} variables.

The general idea of our proposed approach is to define [*non-blocking*]{} [concurrent]{} objects similar to protected objects (cf. e.g., [@Herlihy:2012]). However, entries of [concurrent]{} objects will not block on guards; they will spin loop until the guard evaluates to true. In addition, functions, procedures, and entries of [concurrent]{} objects are allowed to execute and to modify the encapsulated data in parallel. Private entries for [concurrent]{} objects are also supported. It is their responsibility that the data provides a consistent view to the 