Fuzion Logo
fuzion-lang.dev — The Fuzion Language Portal
JavaScript seems to be disabled. Functionality is limited.

atomic

concur.atomic

atomic -- low-level atomic values

Atomic values can be used for communication between threads in a safe
way.

Functions

§
:
Any
 => 
String 
[Inherited from  Any]
create a String from this instance. Unless redefined, `a.as_string` will
create `"instance[T]"` where `T` is the dynamic type of `a`
§(expected concur.atomic.T, new_value concur.atomic.T)
:
Any
 => 
bool
Perform a bit-wise comparison of the value contained in this atomic and
`expected`. In case both values are equal, replace this value with `new_value`.

returns true, if successful
§(expected concur.atomic.T, new_value concur.atomic.T)
:
Any
 => 
concur.atomic.T
Perform a bit-wise comparison of the value contained in this atomic and
`expected`. In case both values are equal, replace this value with `new_value`.

returns the old value, independent of whether the old value is bit-wise
equal to `expected` or not.
§
:
Any
 => 
Type 
[Inherited from  Any]
Get the dynamic type of this instance. For value instances `x`, this is
equal to `type_of x`, but for `x` with a `ref` type `x.dynamic_type` gives
the actual runtime type, while `type_of x` results in the static
compile-time type.

There is no dynamic type of a type instance since this would result in an
endless hierarchy of types. So for Type values, dynamic_type is redefined
to just return Type.type.
§
:
Any
 => 
String 
[Inherited from  Any]
convenience prefix operator to create a string from a value.

This permits usage of `$` as a prefix operator in a similar way both
inside and outside of constant strings: $x and "$x" will produce the
same string.
Does the current system permit racy accesses to the value of type T
stored in this atomic?

This is typically true for ref values and for small primitive types
such as `i32`, `f64`, etc. while this is typically not the case for
more complex types such as `point(x,y i64)`.
§
:
Any
 => 
concur.atomic.T
read the value stored in this atomic and do not care about synchronization.

In case of concurrent write operations, the result that is read may be
outdated. In the presence of concurrent writes and no synchronization,
out-of-thin-air values are possible (see https://dl.acm.org/doi/10.1145/3276506).

In general, this is useful only for debugging or monitoring purposes where
occasionally wrong random results are acceptable.
§(new_value concur.atomic.T)
:
Any
 => 
unit
write a value in this atomic and do not care about synchronization.

Note that in conjunction with `racy_read`, this might create arbitrary
out-of-thin-air values.
§
:
Any
 => 
concur.atomic.T
read this value in a way that is atomic with respect to write operations
performed by concurrent threads
§
:
Any
 => 
concur.atomic.T 
[Redefinition of auto_unwrap.unwrap]
unwrap this atomic value

redefines:

§(new_value concur.atomic.T)
:
Any
 => 
unit
write this value in a way that is atomic with respect to read and write
operations performed by concurrent threads

Type Features

§
:
Any
 is
 
[Inherited from  Type]
string representation of this type to be used for debugging.

result has the form "Type of '<name>'", but this might change in the future

redefines:

§
:
Any
 is
 
[Inherited from  Type]
There is no dynamic type of a type instance since this would result in an
endless hierarchy of types, so dynamic_type is redefined to just return
Type.type here.

redefines:

§(T 
type
)
:
Any
 is
 
[Inherited from  Type]
Is this type assignable to a type parameter with constraint `T`?

The result of this is a compile-time constant that can be used to specialize
code for a particular type.

is_of_integer_type(n T : numeric) => T : integer
say (is_of_integer_type 1234) # true
say (is_of_integer_type 3.14) # false

it is most useful in conjunction preconditions or `if` statements as in

pair(a,b T) is

=>

or

val(n T) is

§
:
Any
 is
 
[Inherited from  Type]
name of this type, including type parameters, e.g. 'option (list i32)'.
§
:
Any
 is
 
[Inherited from  Any]
Get a type as a value.

This is a feature with the effect equivalent to Fuzion's `expr.type` call tail.
It is recommended to use `expr.type` and not `expr.type_value`.

`type_value` is here to show how this can be implemented and to illustrate the
difference to `dynamic_type`.