The nodal model

1. Introduction

Why do we need to start at such a basic level, when powerful high-level data-structures already exist in most programming environments that can easily support this? because:

• Wikipedia:Mutex
• Wikipedia:Linearizability
• Wikipedia:Non-blocking synchronization
• Wikipedia:Lock-free and wait-free algorithms (a fragment extracted follows)

Writing a program that uses lock-free data structures is not a simple matter of merely rewriting the algorithms you would normally protect with a mutex to be lock-free. Because lock-free algorithms are so difficult to write, researchers focus on writing lock-free versions of basic data structures such as stacks, queues, sets, and hash tables. These allow programs to easily exchange data between threads asynchronously.

For example, consider a banking program where each thread represents a virtual teller. A lock-based approach to making a deposit could be to have one teller lock an account to make a deposit, so that two tellers don't try to deposit into the same account simultaneously. To make the process lock-free, rather than designing a lock-free "deposit" algorithm you might have the teller submit a "deposit" request asynchronously to a centralized thread that handled all deposits.

Each different programming language has it's own strengths and weaknesses across many different contexts such as efficiency, portability, scalability, availability of programmers, application-vendor support, protocol/standards support etc. But one area which is common to all languages and benefits greatly from unification is the concept of program-flow.

The concept of program-flow itself comes in many flavours which appear in all combinations across the different programming environments. Some of these program-flow concepts are subroutines, conditional-structures, looping structures, event models and multi-threading models.

The nodal model can completely replace the program-flow aspects of the environments with a unified organisational environment in which the functions and objects of other languages are managed and executed to a schedule.

The nodal model does not use methods as such, but rather is more of a code-snipit model allowing larger code-fragments to be made from executing threads of snipits. Snipits are organised by language and environment bindings.

This organisational environment is recursive and can therefore not only form applications from the organisation of function-execution, but also forms real-world organisations by integrating the same organisational environment with our own goals, roles, and resources.

• Moment: A moment is purely instance. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
• P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.

See Also

• Aspect Oriented Programming
• Instance-Based Programming
• Self Programming Language
• Diff

1. Applicable concepts

Here's a list of concepts from Wikipedia which all apply to this model helping to describe what it is. The peer software...

• is a Prototype-based programming environment
• is an Aspect-oriented programming environment
• is a Metaprogramming environment
• is an Intentional Programming environment
• is an Integrated development environment
• has Reflection
• is a Dynamic programming language
• is an Internet Operating System

1. +The Nodal Model and OO

1. To Add

• Threads: conversation, list of instructions, phases or cycles of operation. These phases can also loop in a cycle like seasons or days of the week. The items that make up these lists are in general called Moments. Threads are not instances, they can only exist conceptually. There can never be any such thing as an actual thread because only one part of it can exist "in the Now". It's because the thread-nature of it stretches along the dimension of time.
• Moments: A moment is purely instance. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
• P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
• See also Diff

1. Schedule

The schedule is used at all layers; process execution, application, people and organisations. Here we discuss it in terms of the concepts and processes which make it up.

• Entropy & Potential
• Auto reduction

1. Resource

The nodal version of the storage concept is actually Resource; the general idea of allocating, or "booking" the use of any kinds of resources to a schedule.

---