8/29/16

Idempotence, Invariants, State, Observable Moments.

Idempotence & State.

There's confusion & ambiguity with idempotence definitions in Computer Sciences & Mathematics.

In Mathematics, an unary operation (or function) is idempotent if, whenever it is applied twice to any value, it gives the same result as if it were applied once; i.e., ƒ(ƒ(x)) ≡ ƒ(x). For example, the absolute value function, where abs(abs(x)) ≡ abs(x).

There's more in this Wikipedia article as well.

In a context of this blog, we can call an object's method call 'strongly idempotent' when calling it multiple times - in any amount of calls - gives the same result, on condition that passed parameters are the same.

In a context of this blog we can call an object's method call 'weakly idempotent' when calling it multiple times - in any amount of calls - gives the same result, on condition that object's state is same between (& at) the method calls & passed parameters are the same; that is - this requires independence from external conditions such as database data or CPU Clock's state for example.


Invariants.

Invariants are properties of the class or method that happen all the time, or at least in all of the 'observable moments'.

For example we can have invariant that states:
- during the observable moments, state variable 'a' has a value of less than 5.


Observable Moments, Unobservable State.

Observable moments have something to do with Physics, but in Computing it's also related with concurrency mechanisms.

In Computer Sciences objects' methods' accessors can be 'synchronized' using the Monitor Mechanism for example; then only one thread or process can enter the method at once, during an 'observable moment'.

Other processes or threads have to wait in queue until initial thread or process leaves; during that time of the wait other threads or processes cannot access method & state so it's 'nonobservable moment' for these - at least when all state accessing methods are synchronized with the same wait queue; there are other causes for 'nonobservable moments' as well - for example when inner or external mechanism blocks access to the object's state & methods.

This is little vague explaination can be reduced to a process/thread synchronization & concurrency even if it's internally managed by interpreter, or included by a compiler in executable code. This works the same both with time division between a nonconcurrent CPU's processes or threads, as well as with a multi-core or multi-processor architecture concurrency.

There's also possibility of 'hardware blocks' that make parts of the code 'nonresponsive', it's state 'unobservable'.

No comments:

Post a Comment