Why application specific library construction is necessary ?

In a multithreaded program, there are more than one flow of executions ( threads) and these threads share the process resources. In many cases, the threads either communicates each others or share common variables. In addition to this, in most of the multithreaded applications, the threads execute different function routines and perform different jobs. Therefore, unfortunately, the structure of a multi-threaded program may differs according to the requirements of the application to be developed. For each application, the answer of the questions given in below may change.

How many thread will be created on the program ?

Which thread function will be executed by which thread ?

Will be there a communication between the threads ?

How many function will be executed by the threads ?

Will the threads share a common memory or variable ?

This structural diversity increases the gab between the control functions that are used for thread management and the programmer. On the single threaded applications, we don’t face this diversity. Because, a single program flow stars from a one point and the same input always gives the same output. Therefore, single threaded applications has input-output determinism. More specifically, on the single threaded applications, each code line is executed in an exactly same order and the output of the program never changes. On the contrary, on the multi-threaded applications, there are multiple flow of execution and the scheduling of the threads are performed by the operating system and underlying hardware. The execution order and the priority of the threads reflect the term of scheduling. More specifically, it is a decision about which thread will run and which thread will be suspended in a particular time interval. In practice, the programmer can not control the scheduling of the threads on the applications in which a standard multi-threading library such as C++ std::threads is used. In other words, the decision about which code section will be executed by which thread on particular time interval is given independently from the programmer. Therefore, the threads are scheduled randomly. Actually, this is the biggest reason of the non-determinism in multithread programming. This situation breaks down the input-output determinism of the multi-threaded applications and it plays a crucial role on the deadlocks as well. Beside to this, in a deterministic multi-threading, on the each running of the programs, the code sections are executed with exactly the same order. A figure which illustrates the difference between the deterministic multi-threading and non-deterministic multi-threading has been given in below.

The Figure-A depicts non-deterministic multi-threading and on each running of the program, a different scheduling scenario has been followed. However, the Figure-B depicts deterministic multi-threading and on the each run of the program, exactly the same scheduling scenario has been followed. However, non-deterministic scheduling of the threads breaks down input-output determinism of the multi-threaded software and thus, developing, debugging and testing a non-deterministic multi-threaded application is very difficult.

Now, let us remember that the structure of the multi-threaded applications and the architecture of the program to be developed may change according to the requirements of the application. On the multi-threaded applications, there are infinite number of possible program structure which may change depending on the number of the threads and the thread functions. Therefore, on the multi-threaded applications, constructing a unified tool that provides absolute control over the threads for every possible multi-threaded application is impossible.

Beside to this we can consider that every possible structure of a multi-thread software defines a big set. In order to gain more control over the threads, we must strictly define the relation between the threads and perform some restrictions on this set. This is the reason why we need an application specific library construction process. If the programmer defines the number of the threads and the thread functions which are executed by the threads, a threading library that you can gives a unique number for each thread and control the threads by means of these numbers.

By this way, on the applications that is developed with pcynlitx, the programmers can set numbers to the threads and block and rescue the threads by means of these numbers and deterministic scheduling is achieved. From different point of view, we can easily said that pcynlitx solves the problems caused by the non-deterministic scheduling of the threads.

HOW PCYNLITX DIFFERS FROM THE OTHER TOOLS ?

With Pcynlitx, you will have a threading library that is specialized according to your needs. The control tools that are build by the Pcynlitx has a memory and can receive information from the process. In other words, the control tools of the Pcynlitx communicate the process after each operation that is performed on the process. This communication can be considered as a feedback mechanism which provides situation awareness. Therefore, you can give a unique number for each thread and you can control the threads by means of these unique numbers. More specifically, you can stop and rescue each threads with its unique numbers. This property provides more control over the threads. For instance, let we look at the illustrative program depicted in the below figure.

In the figure, the function call depicted as “wait ( 1, 2 )” stops “thread-1.” The same function call also records that the “thread-1” will be rescued by the “thread-2” later on. This means that the pcynlitx also defines the relation between the threads and reduces non-determinism of the multi-threading. In the program, “thread-1” always waits on the code line in which wait(1,2) function call is performed until its corresponding rescue function is called by “thread-2” . Therefore, the “Code Block -2” is always executed before the “Code Block -1”. More specifically, the programmer can determine exactly which thread will be blocked by which thread and how and in which place the threads will be rescued later on. Standard threading libraries don’t have such a control over the threads and thanks to the autonomous thread management system, Pcynlitx has many other advance properties which the other threading libraries doesn't have. In order to learn how pcynlitx produces an application specific library and how provides such a control over the threads, please look the following link.

Home Page