Adaptation of the technology of the static code analyzer for developing parallel programs


Published on

In the article the question of use of the static code analyzers in modern parallel program development processes is considered. Having appeared in 70-80s as an addition to compilers, the static analyzers stopped to be popular with the developers in 90s. The reason was probably the increase of the errors diagnostics quality by the compilers. But in 2000s the interest to the static code analyzers started to increase again. It is explained by the fact that new static code analyzers were created, which started to detect quite difficult errors in programs. If the static code analyzers of the past made it possible, for example, to detect an uninitialized variable, modern static code analyzers tend to detect an unsafe access to data from several threads. The modern tendency of static code analyzers development became their use for diagnosing errors in parallel programs. In the work the situations are considered, where the use of such tools makes it possible to considerably simplify the process of creating parallel program solutions.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Adaptation of the technology of the static code analyzer for developing parallel programs

  1. 1. Adaptation of the technology of the staticcode analyzer for developing parallelprogramsAuthors: Andrey Karpov, Evgeniy RyzhkovDate: 16.02.2008AbstractIn the article the question of use of the static code analyzers in modern parallel program developmentprocesses is considered. Having appeared in 70-80s as an addition to compilers, the static analyzersstopped to be popular with the developers in 90s. The reason was probably the increase of the errorsdiagnostics quality by the compilers. But in 2000s the interest to the static code analyzers started toincrease again. It is explained by the fact that new static code analyzers were created, which started todetect quite difficult errors in programs. If the static code analyzers of the past made it possible, forexample, to detect an uninitialized variable, modern static code analyzers tend to detect an unsafeaccess to data from several threads. The modern tendency of static code analyzers developmentbecame their use for diagnosing errors in parallel programs. In the work the situations are considered,where the use of such tools makes it possible to considerably simplify the process of creating parallelprogram solutions.IntroductionOne of the actively developing tendencies in the sphere of computer engineering is parallel computing.Parallelism becomes the basis of the growth of efficiency, which is connected with the slowdown of rateof growth of clock frequency of modern microprocessors. If during the latest 30 years the efficiency wasdetermined by the clock frequency, optimization of commands execution, cache increase, then in thenearest years it will be determined by multi-core.The processors producers shifted the accent from increasing the clock frequency to the realization ofthe parallelism in the processors proper at the expense of using multi-core architecture. The essence ofthe idea is to integrate more than one core into one processor. This approach makes it possible to avoidmany technological problems connected with increasing clock frequencies and to create at the sametime more efficient processors. The system including the processor with two core in fact does not differfrom two-processor computer and the system with a four-core processor does not differ from a four-processor computer.It is very difficult for the programmers who have begun to use multi-core systems to direct themselvesin all the details of their using during developing programs of classic applications. As the practice shows,the difficulties begin when the claims of the efficiency and mobility are laid to the parallel softwareunder development. It is connected with the fact that universal tools that facilitate the work of theprogrammer and provide a full access to debugging information are on the stage of development. Theproblem consists in the absence of standards in the sphere of creating and debugging programs forparallel systems for the reason of the computing sphere being young.
  2. 2. The development of multi-core computing machinery is closely connected with the development of thetechnology of parallel programming, both universal and under a certain architecture of a specificsystem. One of the directions in the sphere of improvement of the methodology of parallelprogramming is the research work in the sphere of static program code analyzer with the aim ofrevelation of errors typical of parallel application.1. The perspectives of systems of development and testing parallelprogramsA joke is popular with the specialists who are occupied with parallel calculations: "Parallel computing isthe technology of the future, and this will be ever urgent". This joke has kept its urgency for severaldecades already. Similar spirits were spread among the community of computers architecturedevelopers, concerned by the fact that the limit of clock frequency of processors will be reached soon,though much slower than before. The fusion of specialists optimism about parallel calculations andsystems architects pessimism favored the appearance of revolutionary multi-core processors [1].Parallel computing ceased to be the privilege of large hardware-software complexes meant for big tasksand now come to be a means for solving everyday tasks linked with work, studies, entertainment,computer games, medicine.But a huge layer of tasks connected with software development that takes into account the aspects ofparallel programming is clearly observed at the introduction of new highly efficient parallel countingsystems. The development of parallel software is a difficult task, which is now taken up mainly byresearch institutes of modeling, organizations connected with the data bulk and other bigestablishments. But this is not practically taken up by ordinary programmers, who take part indeveloping applied software for an ordinary user. Such programs are in majority and as a consequencethe majority of programmers have never run across the tasks of parallel data processing.The crisis in the sphere of software development is outlined connected with the forthcoming of multi-core systems at the mass market. And this crisis will be connected with the lack of specialists creatingand supporting parallel code or capable of modifying older developments taking into consideration thetechnology of paralleling. Such specialists are quite few and are well placed and have a good well-paidjob.Naturally many programmers will later master new technologies and will get the skill of creating parallelcode. But a lot of time will pass and not everyone will be likely to realize such transition successfully. Thething is that the technology of parallel programming is much more difficult than other technologieschanges like, for example, migration from C++ to C# or from 32-bit systems to 64-bit. Parallelprogramming requires from a person the knowledge of theory of parallel algorithms, synchronization,means of construction of parallel code and many other things.The necessity of tools facilitating the adaptation and testing the existing software for multi-corecounting systems will naturally occur.Many steps are taken and a number of decisions and methodologies are offered in the direction ofautomation and facilitating the creation of parallel program systems. The examples are: MPI, OpenMP,Intel Threading Analysis Tools, or, for example, a Russian development OpenTS [2] by Program SystemsInstitute of the Russian Academy of Sciences. But the existence of all these systems unfortunately does
  3. 3. not give the opportunity to speak of complex solution of problems, which a beginning or an experiencedprogrammer comes across.If the questions of the technologies making it possible to create parallel programs can be consideredclosed, then the questions of testing and verification of parallel program code demand great attentionand creating corresponding support systems.2. Dynamic and static analysis as the most perspective methods fortesting parallel codeThe main ways of program code verification are: the program proof, white box method, black boxmethod, code review, dynamic code analysis, static code analysis. Unfortunately, in case of parallel codethe greatest practical result is presented by two last methods only. We will try to give proof the thisstatement.The program proof. It does not raise any doubts that only this approach makes it possible to guaranteean algorithm correctness [3]. But the research of parallel programs must not be carried out in terms ofrelations between incoming and outcoming data of the program like it is usually for thesuccessive/consecutive programs. This show that the verification and proof of the correctness of work ofsuch programs demands the development of adequate means of formal specification. In particular, it isnecessary to have an opportunity to formally express the relation between the states of the system atthe moments of time when these or those take place during the work of the program system [4].Adding extra complexity makes this approach even more tedious and grounded only at creating criticalprogram systems. If to take into account the fact that the proof of code correctness is not practicedeven for series code, then we cant consider this method as practical methodology of parallel programsverification.White box method. Let us understand under the white box method testing the execution of highestavailable quality of different parts of the code with the use of debugging or other tools. The morecoverage of the code was achieved, the more completely the testing was carried out. The white boxmethod is sometimes also understood as a simple application debugging with the aim of finding acertain error. A complete testing with the help of a white box method has become impossible long timeago due to huge code volume of modern programs. In case of parallel programs this method may turnout to be absolutely useless and inapplicable in practice. The reason consists in the fact that, like in thephysic of elementary particles, the effect is observed when a change of a certain parameter influenceson the state of the whole system. Thus, it is possible to make a conclusion that this method is of nogreat practical interest.The black box method established a much better reputation. Unit test can be also referred here. Themain idea of the method consists in writing a set of tests for separate modules and functions, which willverify all the main modes of their work. A number of sources refer a unit test to a white box method forit is based on the knowledge of program organization. The authors tick to the opinion that testedfunctions and modules must be considered as black boxes because unit tests must not take into accountthe inner organization of the function. The ground for it can be the methodology of development whentests are developed before creating the function itself, which favors the increase in the control of theirfunctionality from the point of view of the specification.
  4. 4. The black box method is quite suitable for parallel programs but anyway it cant be the methodproviding a sufficient level of reliability of the verification. At another system with another quantity ofcomputational nodes or at a heterogeneous system a parallel program can behave in a completelydifferent way. This unpleasant peculiarity sufficiently limits the attractiveness of the method in contrastto using it for the verification of usual programs.Code review. This is the oldest, the most proved and reliable approach to searching for any kinds ofdefects. This methodology is based on the combination of code reading with a execution of a set of rulesand recommendations very well described, for example, in Steve McConnells book "Code Complete"[5]. Unfortunately this practice is inapplicable for a large-scale verification of modern program systemsbecause of their big volume. Though this way gives beat results, it is not always used under theconditions of modern life cycles of the software development where a very important moment is theperiod of development and the time of the product release to the market. Thats why the code reviewgenerally comes to rare meetings the aim of which is training new and not less experienced staff towrite a high quality code than for verification of work of a number of modules. This is a very good way ofincreasing programmers qualification but it cant be considered as a complete means for quality controlof a developed system.The methodology of static code analysis, which will be described further, comes to assist theprogrammers who are aware of the necessity of regular code review but do not have enough time. Themain task of the methodology is reducing the code volume demanding the mans attention and thusreducing the time for its review.The dynamic code analysis is a software analysis, which is carried out with the help of executingprograms at a real or virtual processor. A dynamic analysis is often understood as a program code studywith the aim of its optimization. But we will speak of the dynamic analysis as of the method of parallelprograms testing.For dynamic race detection, the program is executed and a history of its memory accesses andsynchronization operations is recorded and analyzed. Because the history is in fact a feasible execution,dynamic detectors typically suffer a lower false positive rate than static detectors. On the other hand,since not all possible execution paths are considered, the dynamic technique is not sound and thuscannot certify a program to be free of data races. The dynamic technique also imposes runtimeoverhead which must be kept within limits while still providing reasonably accurate race detection. Thepost-mortem approach records events during program execution and analyzes them later, or recordsonly critical events and then carefully replays the program. This approach is unsuitable for long-runningapplications that have extensive interactions with their environment. The other approach is to recordand analyze information as efficiently as possible on-the-fly [6].Dynamic parallel code analyzers are already represented by the commercial solutions and have taken adeserved place in a row of other code testing systems (a vivid example is a set of tools Intel ThreadingTools [7]). In the scope of it we will not speak about this dynamic analysis methodology and hope thatthis methodology and corresponding tools will be helpful in creating reliable parallel systems.But like it was mentioned before, dynamic analysis does not make it possible to find all the errors for it isoften impossible to execute the whole tested program code or the succession of its execution will bevery different from the real system. In this case the static analysis will be helpful, and we will describe itin more detail. It is connected with the fact that all researches and realizations in this direction are morelikely to have a theoretical character and need more research and practical work.
  5. 5. Static code analysis is a software analysis which is carried out without real execution of programs underresearch. Depending on the tool which is used the depth of the analysis can vary from defining thebehavior of certain operators to the analysis including all the source code. Lately, the static analysis wasmostly used for verification of software properties, which is used in computer systems of high reliability.In case of parallel programs the static analysis makes it possible to detect errors even in those sectionsof the code, which get called only in very rare cases. Regardless of the stage of execution, static analysismakes it possible to detect potential errors which may not show up during the work at the whole classof apparatus or program systems. The static analysis can thus substantially complement dynamicanalysis and be effectively used in parallel software development life cycle.3. The sphere of effective application of static parallel code analyzerThe obstacle on the way of wide introduction of static analysis method consists in the fact that difficultyof creating such systems is much higher than dynamic ones. Thats why in the network of this article wewill offer not an attempt to describe and create an ideal analyzer but to find a sphere of application forwhich the creating of the analysis is an observed task and can give a good practical effect.For this reason let us consider main levels of decomposition of the task in case of creating parallelalgorithms. Let us name these levels: • Division of tasks into subtasks. • Division of subtasks into many quasi-homogeneous procedures which are executed at the same time with different source data. In the mathematical physics such type of parallelism is called geometrical parallelism for paralleling here is carried out with the help of calculations distribution in different points of calculation sphere into different processors. • Paralleling different procedures. • Paralleling certain processor commands. Optimizing compilers and processors proper cope with it quite well already.Division of tasks into subtasks. It is an ideal case of paralleling when the task is divided into several partseach of which can be solved separately. In this case the system of interaction of parallel threads is quitesimple and theres no sense to talk about a static analysis.Division of each subtask into many parallel procedures. On the one hand it is the most interesting levelfor analysis. This is exactly the level of parallel procedures where the most part of mistakes is made,which is connected with particular difficulty of such systems. This level is also interesting with the factthat it helps to achieve good temporary indicators of paralleling. Thats why many researchers start towork with static analysis at this level and find it very difficult. They consider demonstration examples.But when they get to real systems, moreover written on such difficult language a C++, then it becomes avery difficult task to create a working static analyzer. As the result we observe practical absence ofcommercial solutions based only on static analysis. Dynamic-static analysis is practically used when afterthe stage of program execution static analysis is carried out of the received data and source code.Thus, it is possible to make a conclusion that though static analysis is interesting for the second level,but it is difficult to be realized in practice. But one more step can be made on getting lower to the thirdlevel, which is often forgot, and to find out that this is the very level where static analysis can give thebest result.
  6. 6. This is the level of different systems organizing the execution of both separate functions and sectors offunction code. MPI, OpenMP, OpenTS can be referred here. Exactly for such systems the use of staticcode analyzers is considered the most reasonable.We will consider the possibility of application of static code analyzer on the example of OpenMP as themost actively developing technology. The standard OpenMP was developed in the year 1997 as API,aimed at writing sorted multithread applications. First it was based on Fortran language but laterincluded C/C++. The last version of OpenMP is 2.0; it is fully supported by Visual C++ 2005. The standardOpenMP is supported by the platform Xbox 360.4. Static code analysis on the example of the technology OpenMPLet us consider two simple examples demonstrating the cases where static analyzers may be helpful, forexample, in the process of writing a new code. Let us imagine that a programmer written the followingcode:size_t i;#pragma omp parallel sections num_threads(2){ #pragma omp section { for (i = 0; i != arraySize; ++i) array[i].a = 1; } #pragma omp section { for (i = 0; i != arraySize; ++i) array[i].b = 2; }}Picture 1 - First example.In this example the error consists in using one variable i for the two simultaneously executed cycleswhich leads to an emergency program completion. The troubleshooting of this error can be easilyrealized in a static analyzer with the help of verification that the same variable is used for recording intwo parallel sections. Of course such mistake is likely to be detected at the testing stage, but theintegration of a static analyzer in the process of development can substantially save time at the expenseof preliminary analysis just before the beginning of the testing.
  7. 7. The next example is also very simple, but it can arouse the necessity to spend much time on searchingan error. This code leads to calculation of the wrong magnitude of the sum aroused by the absence ofOpenMP directive reduction(+: sum).int sum = 0;#pragma omp parallel num_threads(2){ #pragma omp for for (int i = 0; i < arraySize; ++i) sum += array[i];}_tprintf(_T("sum=%in"), sum);Picture 1 - Second example.Such constructions of recording in variable sum from two threads is also easily diagnosed by staticanalyzers and make it possible to substantially facilitate the work on program code verification.ConclusionAs it was said before, no commercial static analyzers for parallel systems support are represented at themarket At the same time, theres no doubt in the necessity of creating such tool, for the existing meansof development of parallel programs do not make it possible to solve all the problems. Let us describeone more time what such solution may look like. The developer prepares parallel code and then startsthe static analyzer, which informs whether the code is correct or not. In case if the developed codecontains errors, then the diagnostic message will make it possible to quickly find and correct it.We hope that on appearance of the tool of static parallel code analyzer the amount of program errors inthe developed systems will reduce.References 1. Kang Su Gatlin, Pete Icency. OpenMP and C++ // MSDN Magazine #10, 2005. 2. Sergey Abramov, Alexei Adamovich, Alexander Inyukhin, Alexander Moskovsky, Vladimir Roganov, Elena Shevchuk, Yuri Shevchuk, and Alexander Vodomerov. 2005. OpenTS: An Outline of Dynamic Parallelization Approach. Parallel Computing Technologies: 8th International Conference, PaCT 2005, Krasnoyarsk, Russia, September 5-9, 2005. Proceedings. Editors: Victor Malyshkin - Berlin etc. Springer, 2005. - Lecture Notes in Computer Science: Volume 3606, pp. 303-312 3. Daykstra E, The programming discipline. M.: Mir, 1978. 4. Valiev M.K. Application of temporary logics to programs specification. // Programming. 1998, 2, p. 3-9. 5. Steve McConnell, "Code Complete, 2nd Edition" Microsoft Press, Paperback, 2nd edition, Published June 2004, 914 pages, ISBN: 0-7356-1967-0.
  8. 8. 6. Yuan Yu, Tom Rodeheffer, Wei Chen. RaceTrack: Efficient Detection of Data Race Conditions via Adaptive Tracking // SOSP05, October 23-26, 2005, Brighton, United Kingdom.7. Clay R. Breshirs, The set of instruments Intel Threading Tools and OpenMP library.