<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>PETERSON'S ALGORITHM TOTAL CORRECTNESS PROOF IN IPCL</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>A.A. Zhygallo</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>IPCL Syntax The syntax of such languages is defined as follows:</institution>
          <addr-line>P::= P1;P2</addr-line>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2016</year>
      </pub-date>
      <abstract>
        <p>The total correctness of the Peterson's Algorithm has been proved. States and transitions were fixed by the program. Runtime environment considered is interleaving concurrency with shared memory. Invariant of the program was constructed. All reasoning provided in terms of Method for software properties proof in Interleaving Parallel Compositional Languages (IPCL). Conclusions about adequacy of the Method usage for such a kind of tasks (thanks to flexibility of composition-nominative platform) and its practicality as well as ease of use for realworld systems have been made based on this and other author's works.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>if b then P1 else P2 |
while b do P |
x:=e|
P1 || P2,
where x:=e is an atomic, vector assigning and P1 || P2 implies interleaving parallelism.</p>
    </sec>
    <sec id="sec-2">
      <title>IPCL Semantics</title>
      <p>Let us define compositional semantics of IPCL. The semantics of the first three compositions is standard while
semantics of interleaving parallelism is defined through its arguments semantics and syntactic context in traditional way
with its algebraic and semantic properties. An Index-parameter of the semantics function is a syntactic context - piece of
the program or the program itself. So:</p>
      <sec id="sec-2-1">
        <title>Semantics of “;”:</title>
        <p>sem A ; B (d) = d —’ sem A (d) —’ sem B (d —’ sem A (d))
where —’ – component-wise superposition of Cartesian product of nominative data:
d1 —’ d2 = (Pr1(d1) — Pr1(d2), Pr2(d1) — Pr2(d2))
Pri(d) is a projection of the Cartesian product d by the i-th component, d1, d2 Œ D¥D,</p>
        <p>
          This small modification is due to the fact that data is considered as two-component one – such that contains
"global" and "local" parts and — – is a simple operation of the data superposition (two nominal or nominative sets) in
accordance with [
          <xref ref-type="bibr" rid="ref10 ref11 ref9">9–11</xref>
          ] here.
        </p>
        <p>Semantics of “:=”:
sem x := e (d) = d —’ f (d),
where f Œ Oper – is a (semantic) fucntion, which complies with syntactic operator x := e. An assignment (the result of f)
provides two-component result, as global and local data are evaluated, and superposition is occurring to the relevant
components of d data: global variables – to the first component, local variables – to the second; x and e are the vectors
of names and values (expressions) respectively,</p>
        <p>semantics of “if”:
sem if b then P else Q (d) = sem P (d), iff b(d) = True,
sem if b then P else Q (d) = sem Q (d), iff b(d) = False,</p>
        <p>semantics of “while”:
sem while b do P (d) = sem P ; while b do P (d), iff b(d) = True,
sem while b do P (d) = d, iff b(d) = False,
semantics of “||”:
|| is associative and commutative:
sem ( A || B ) || C (d) = sem A || ( B || C ) (d)
sem A || B (d) = sem B || A (d)</p>
        <p>on the syntactic level it means respectively:
((A || B) || C) (d) = (A || ( B || C )) (d)
(A || B) (d) = (B || A) (d)</p>
        <p>|| relatively to “if”:
sem if b then P else Q || R (d) = sem P || R (d), iff b(d) = True,
sem if b then P else Q || R (d) = sem Q || R (d), iff b(d) = False,
sem if b then P else Q ; P’ || R (d) = sem P ; P’ || R (d),
iff b(d) = True,
sem if b then P else Q ; P’ || R (d) = sem Q ; P’ || R (d),
iff b(d) = False,
|| relatively to “while”:
sem while b do P || R (d) = sem P ; while b do P || R (d),
iff b(d) = True,
sem while b do P || R (d) = sem R (d),
iff b (d) = False,
sem while b do P ; P’ || R (d) = sem P ; while b do P ; P’ || R (d),
iff b (d) = True,
sem while b do P ; P’ || R (d) = sem P’ || R (d),
iff b (d) = False,</p>
        <p>|| relatively to “;”:
sem ( A ; B ) || P (d) = sem A ; ( B || P ) (d),
sem A || P (d) = sem A ; P (d),
where A, B, C, P, P’, Q, R Œ Terms – programs in IPCL (terms in IPCL Algebra), b is a syntax notation of an
appropriate condition of the predicate pred from Pred that is b (d) = sem b (d) = pred (d) and d Œ D¥D.</p>
        <p>In all the above definitions if the value of b (d) is undefined then the value of the left side of the relevant equality
will also be undefined. Similarly, if any of the definitions of the right side of equality is undefined then the value of the
left side is undefined.</p>
        <p>
          F is a set of functions for the data conversion, C is the compositions over functions from F. F=Oper»Pred,
where Oper=D¥D Æ D¥D and Pred=D¥D Æ {True, False}, where the first occurrence of D to the Cartesian product is
“global data” while the second is “local data” for the current process; functions which return values from the set
{True, False} (predicates) do not change the current state (i.e. does not have “side effect”) of data D¥D – they are used
as conditions in branching and cycle operators; D=ND(V,W) in the usual sense (as simple nominative data [
          <xref ref-type="bibr" rid="ref10 ref11 ref9">9–11</xref>
          ]).
        </p>
      </sec>
      <sec id="sec-2-2">
        <title>The specific IPCL class language is formed by fixing F. The functions from F are atomic transactions which are indivisible in the sense of parallelism – their execution cannot be interrupted. Thus, the conditions in compositions are also atomic.</title>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Peterson’s algorithm notation in IPCL</title>
      <p>The main idea of the Peterson’s algorithm is to use three variables, flag1, flag2 and turn. flag1 or flag2 value of
1 indicates that the process n wants to enter the critical section. Entrance to the critical section is granted for process T1
if T2 does not want to enter its critical section or if T2 has given priority to T1 by setting turn to 1. Also entrance to the
critical section is granted for process T2 if T1 does not want to enter its critical section or if T1 has given priority to T2
by setting turn to 2.</p>
      <p>
        According to the method for program’s properties correctness proof [
        <xref ref-type="bibr" rid="ref1 ref12 ref13 ref5">1, 5, 12</xref>
        ] the sources of T1 and T2 programs
with labels will have the form:
T1≡ [M11] flag1≔ 1;
      </p>
      <p>[M12] turn∶ = 2;
T2≡ [M21] flag2∶ =1;
[M22] turn∶ = 1;
while [M13] (flag2 = 1 &amp;&amp; turn = 2) do
skip;
[M14] r≔ do_critical_operations(); //critical section
[M15] flag1∶ = 0;[M16]
while [M23] (flag1 = 1 &amp;&amp; turn = 1) do
skip;
[M24 ] r≔ do_critical_operations(); //critical section
[M25] flag2∶ = 0;[M26]</p>
      <p>In this work while-cycle condition (for instance in T1 program: ????2 = 1 &amp;&amp; ???? = 1) is considered as an
atomic operation while we may as well use the method dividing this process into three independent stages, like:
???????2 = ???? 2;
??????? =????;
?ℎ???(???????2 = 1 &amp;&amp;??????? = 1) do
begin
end;
???????2 =????2;
??????? =????;</p>
      <sec id="sec-3-1">
        <title>This case could be researched as a separate question in further works.</title>
      </sec>
      <sec id="sec-3-2">
        <title>The whole program system will have the following structure:</title>
        <p>??????? =??||??.</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>States and Transitions</title>
      <p>The state of this program will be as follows:
????? = (?1,?2,[????1↦ ?1,????2↦ ?2,???? ↦ ?],?1,?2),
??????????? = {?1 →?2 |?1,?2∈ ??????
(??11(?1,?2) ??12(?1,?2) ??13(?1,?2)∨</p>
      <p>∨ ∨
??14(?1,?2) ??15(?1,?2) ??16(?1,?2)∨</p>
      <p>∨ ∨
??21(?1,?2) ??22(?1,?2)∨??23(?1,?2)∨</p>
      <p>∨
??24(?1,?2) ??25(?1,?2)∨??26(?1,?2)},</p>
      <p>∨
where ?1 ∈ {? ??, ? ??, ? ??, ? ??, ? ??, ? ??} – labels of T1; ?2 ∈ {? ??, ? ??, ? ??, ? ??, ? ??, ? ??} –
labels of T2; [????1 ↦ ?1,????2 ↦ ?2,???? ↦ ?] – global data; d1 and d2 are the local data of T1 and T2 respectively.</p>
      <sec id="sec-4-1">
        <title>States will denote the set of all possible states.</title>
      </sec>
      <sec id="sec-4-2">
        <title>The transition system will have the following scheme of transitions:</title>
        <p>∧
where each predicate??ij ?= 1:2, ?= 1:6 describes the possible program step between states.</p>
      </sec>
      <sec id="sec-4-3">
        <title>For program T1 we have 6 different steps:</title>
      </sec>
      <sec id="sec-4-4">
        <title>1. Move M11 →M12 (assigning variable flag1 to 1):</title>
        <p>Tr11(S1,S2) = (Pr1(S∧1)= M11) (Pr1(S2) = M12) ∧(Pr2(S1) = Pr2(S2)) ∧(Pr3(S1) = d) ∧(Pr3(S2) = d ∇[flag1↦1]) ∧
∧
(Pr4(S1) = Pr4(S2)) (Pr5(S1) = Pr5(S2))</p>
      </sec>
      <sec id="sec-4-5">
        <title>2. Move M12 → M13 (assigning variable turn to 1):</title>
        <p>Tr12(S1,S2) = (Pr1(S∧1)= M12) (Pr1(S2) = M13) ∧(Pr2(S1) = Pr2(S2)) ∧(Pr3(S1) = d) ∧(Pr3(S2) = d ∇[turn↦2]) ∧
∧
(Pr4(S1) = Pr4(S2)) (Pr5(S1) = Pr5(S2))</p>
      </sec>
      <sec id="sec-4-6">
        <title>3. Move M13 → M13 (true value of while-cycle condition):</title>
        <p>Tr13(S∧1,S2) = (Pr1(S1) = M13) (Pr1(S2) = M13) (Pr2(S1) = Pr2(S2)) ∧(Pr3(S1) = Pr3(S2) = [flag1↦ f1, flag2↦ f2, turn
∧ ∧
∧ ∧ ∧
↦ t]) (Pr4(S1) = Pr4(S2)) (Pr5(S1) = Pr5(S2)) (f2 = 1) (t = 2)</p>
      </sec>
      <sec id="sec-4-7">
        <title>4. Move M13 → M14 (false value of while-cycle condition):</title>
        <p>Tr14(S∧1,S2) = (Pr1(S1) = M13) (Pr1(S2) = M14) (Pr2(S1) ∨=t≠P2r2)(S2)) ∧(Pr3(S1) = Pr3(S2) = [flag1↦ f1, flag2↦ f2, turn
∧ ∧
∧ ∧
↦ t]) (Pr4(S1) = Pr4(S2)) (Pr5(S1) = Pr5(S2)) (f2 ≠ 1</p>
      </sec>
      <sec id="sec-4-8">
        <title>5. Move M14 → M15 (execution of the critical section as ‘atomic’ operation):</title>
        <p>Tr15(S1,S2) = (Pr1(S1) = M14) (Pr1(S2) = M15) ∧(Pr2(S1) = Pr2(S2)) (Pr3(S1) = Pr3(S2)) ∧(Pr4(S1) = d1) ∧(Pr4(S2) =
∧ ∧
∧
func1(d1)) (Pr5(S1) = Pr5(S2))</p>
      </sec>
      <sec id="sec-4-9">
        <title>6. Move M15 → M16 (assigning variable flag1 to 0):</title>
        <p>Tr16(S1,S2) = (Pr1(S∧1)= M15) (Pr1(S2) = M16) ∧(Pr2(S1) = Pr2(S2)) ∧(Pr3(S1) = d) ∧(Pr3(S2) = d ∇[flag1↦0]) ∧
∧
(Pr4(S1) = Pr4(S2)) (Pr5(S1) = Pr5(S2))</p>
      </sec>
      <sec id="sec-4-10">
        <title>Similar transitions could be fixed for program T2.</title>
      </sec>
      <sec id="sec-4-11">
        <title>The set of the fixed Starting states will have the following structure:</title>
        <p>Pr1(S) = M11 ∧Pr2(S) = M21}
StartStates = {S ∈ States |</p>
      </sec>
      <sec id="sec-4-12">
        <title>The Final states are:</title>
        <p>Pr1(S) = M16 ∧Pr2(S) = M26}
FinalStates = {S ∈ States |</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Invariant</title>
      <p>In these terms the mutual exclusion condition for the algorithm, that no two concurrent processes are in their
critical section at the same time, can be formulated as:
ÿ (Pr1(S) ∈ {M14, M15} ∧Pr2(S) ∈ {M24, M25})</p>
      <sec id="sec-5-1">
        <title>The invariant of the program system is:</title>
        <p>∧ ∧ ∧
Inv(S)= I1(S) I2(S) I3(S) I4(S),
where
I1(S) = Pr1(S) ∈ {M12, M13, M14, M15} → flag1 ⇒(Pr3(S)) = 1,
(Pr2(S) ∉ {M24, M25} ∧
I2(S) = Pr1(S) ∈ {M14, M15} →
Pr2(S) = M23 → turn ⇒(Pr3(S)) = 1),
I3(S) = Pr2(S) ∈ {M22, M23, M24, M25} → flag2 ⇒(Pr3(S)) = 1,
(Pr1(S) ∉ {M14, M15} ∧
I4(S) = Pr2(S) ∈ {M24, M25} →
Pr1(S) = M13 → turn ⇒(Pr3(S)) = 2)</p>
        <p>The idea of invariant Inv(S) is clear and follows from the definition of critical section. If T1 is located previously
to while-cycle {M12, M13} or is inside its critical section {M14, M15}, then flag1 = 1, namely it wants to enter critical
section (getting access to the resource). If T1 “goes through” while-cycle {M14, M15}, that means it comes out of the
cycle (entrance to critical section and getting access to the resource), then the other process (T2) is outside critical
section (i.e. not in {M24, M25}), and also if T2 is located previously to critical section {M23} – then it does not have an
access, because it is T1's turn to entrance now: turn = 1.</p>
        <p>
          The proof that invariant holds true over all transitions is rather technical and will not be presented here [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ].
        </p>
      </sec>
      <sec id="sec-5-2">
        <title>It is obvious, that Inv(S) implies that</title>
        <p>Pr1(S) ∈ {M14, M15} → Pr2(S) ∉ {M24, M25} ∧Pr2(S) ∈ {M24, M25} → Pr1(S) ∉ {M14, M15}
which is equal to:
ÿ (Pr1(S) ∈ {M14, M15} ∧Pr2(S) ∈ {M24, M25})
namely, the mutual exclusion condition: for any state S it is not possible to appear in critical section (marks M14, M15
for T1 and marks M24, M25 for T2) for both processes (T1 and T2) at the same time.</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Total Correctness. Proof</title>
      <p>Let us prove that that the program system ??????? = ??||?? will stop in the shown model.</p>
      <p>According to the algorithm structure the only problem space is a cycle. We have to prove that as soon as the
process T2 has finished its work (flag2∶ = 0), the process T1 will leave the cycle (we will not observe the infinite cycle).</p>
      <p>Proof by contradiction: let us suppose that the process T1 after the label M13 will get into the label M13 which
means the true value of the while-cycle condition. According to the transition Tr13(S1,S2) flag2 = 1. From the fact that
none of transitions of T1 will influence the global variable flag2 and from the condition that the process T2 has finished
and thus due to Tr16(S1,S2), we have that flag2 = 0. Got contradiction.</p>
      <p>The same proof is applicable to show that if the process T1 has ended then we will not have the infinite cycle in
the process T2.</p>
      <p>Let us consider the situation where both processes T1 and T2 have infinite cycles at the same time. This situation
is only possible when we observe the transitions in the following order: Tr13(S1,S2) -&gt; Tr23(S1,S2) -&gt; Tr13(S1,S2) -&gt;
Tr23(S1,S2) and so on. Due to Tr13(S1,S2) global variable turn = 2 while due to Tr23(S1,S2) turn = 1 ≠ 2. That means that
the situation where both processes have infinite cycles is impossible.</p>
      <sec id="sec-6-1">
        <title>We have proved that the infinite cycle is impossible and that both processes will end their work.</title>
      </sec>
    </sec>
    <sec id="sec-7">
      <title>Conclusion</title>
      <p>Together with the other results (besides this work) total correctness of well-known Peterson’s Algorithm was
proved. Namely, we have:</p>
      <sec id="sec-7-1">
        <title>1) noted the algorithm in IPCL terms,</title>
      </sec>
      <sec id="sec-7-2">
        <title>2) provided semantics in terms of states and transitions,</title>
      </sec>
      <sec id="sec-7-3">
        <title>3) formulated invariant of the program,</title>
      </sec>
      <sec id="sec-7-4">
        <title>4) proved the liveness correctness (impossibility of the infinite cycles).</title>
        <p>According to the wide range of difficulties of total correctness proofs in parallel environments, we may state that
the IPCL method is well adapted to parallel software verification. Moreover, this method let us make the proof shorter
by choosing an adequate level of abstraction of the problem due to the universality of composition-nominative
languages.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. PANCHENKO,
          <string-name>
            <surname>T.</surname>
          </string-name>
          (
          <year>2006</year>
          )
          <article-title>Compositional Methods for Software Systems Specification</article-title>
          and Verification (
          <source>PhD Thesis)</source>
          , Kyiv,
          <volume>177</volume>
          p.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2. OWICKI S.,
          <string-name>
            <surname>GRIES D.</surname>
          </string-name>
          (
          <year>1976</year>
          )
          <article-title>An Axiomatic Proof Technique for Parallel Programs</article-title>
          .
          <source>Acta Informatica</source>
          , Vol.
          <volume>6</volume>
          , № 4, pp.
          <fpage>319</fpage>
          -
          <lpage>340</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. XU Q.,
          <string-name>
            <surname>de ROEVER W.-P.</surname>
          </string-name>
          , HE J. (
          <year>1997</year>
          )
          <article-title>The Rely-Guarantee Method for Verifying Shared Variable Concurrent Programs</article-title>
          .
          <source>Formal Aspects of Computing</source>
          , Vol.
          <volume>9</volume>
          , № 2, pp.
          <fpage>149</fpage>
          -
          <lpage>174</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4. LAMPORT L.
          <article-title>(1993) Verification and Specification of Concurrent Programs. A Decade of Concurrency, deBakker J</article-title>
          ., deRoever W.,
          <string-name>
            <surname>Rozenberg</surname>
            <given-names>G</given-names>
          </string-name>
          . (eds.), Berlin: Springer-Verlag, Vol.
          <volume>803</volume>
          , pp.
          <fpage>347</fpage>
          -
          <lpage>374</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5. PANCHENKO,
          <string-name>
            <surname>T.</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <article-title>The Methodology for Program Properties Proof in Compositional Languages IPCL</article-title>
          .
          <source>In Proceedings of the International Conference "Theoretical and Applied Aspects of Program Systems Development" (TAAPSD</source>
          '
          <year>2004</year>
          ), Kyiv, pp.
          <fpage>62</fpage>
          -
          <lpage>67</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>TANENBAUM</surname>
            ,
            <given-names>A.S.</given-names>
          </string-name>
          (
          <year>2008</year>
          )
          <article-title>Modern operating systems, 3Ed</article-title>
          . Upper Saddle River, NJ: Pearson Prentice Hall,
          <volume>1104</volume>
          p.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. PETERSON,
          <string-name>
            <surname>G.L.</surname>
          </string-name>
          (
          <year>1981</year>
          )
          <article-title>Myths About the Mutual Exclusion Problem</article-title>
          .
          <source>Information Processing Letters</source>
          ,
          <volume>12</volume>
          (
          <issue>3</issue>
          ), pp.
          <fpage>115</fpage>
          -
          <lpage>116</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8. ZHYGALLO A.,
          <string-name>
            <given-names>OSTAPOVSKA</given-names>
            <surname>Yu</surname>
          </string-name>
          ., PANCHENKO T. (
          <year>2015</year>
          )
          <article-title>Peterson's Algorithm for Mutual Exclusion Correctness Proof in IPCL</article-title>
          . Bulletin of Taras Shevchenko National University of Kyiv.
          <source>Series: Physical &amp; Mathematical Sciences, N 4.</source>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>REDKO</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          (
          <year>1978</year>
          )
          <article-title>Compositions of Programs and Composition Programming</article-title>
          .
          <source>Programming</source>
          ,
          <volume>5</volume>
          , pp.
          <fpage>3</fpage>
          -
          <lpage>24</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>REDKO</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          (
          <year>1979</year>
          )
          <article-title>Foundation of Composition Programming</article-title>
          .
          <source>Programming</source>
          ,
          <volume>3</volume>
          , pp.
          <fpage>3</fpage>
          -
          <lpage>13</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>NIKITCHENKO</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          (
          <year>1998</year>
          )
          <article-title>A Composition Nominative Approach to Program Semantics</article-title>
          .
          <source>Technical Report</source>
          IT-TR:
          <fpage>1998</fpage>
          -
          <lpage>020</lpage>
          . Technical University of Denmark. 103 p.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>PANCHENKO</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          (
          <year>2008</year>
          )
          <article-title>The Method for Program Properties Proof in Compositional Nominative Languages IPCL</article-title>
          .
          <source>Problems of Programming. 1</source>
          . pp.
          <fpage>3</fpage>
          -
          <lpage>16</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          <article-title>1 Ukrainian publication</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>http://orcid.org/0000-0002-2976-3250.</mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          <string-name>
            <surname>Taras</surname>
          </string-name>
          Shevchenko National University of Kyiv, 4D Academician Glushkov avenue, Kyiv, Ukraine,
          <volume>03680</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          Tel.: +
          <volume>38</volume>
          (
          <issue>063</issue>
          )8795790/
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>