The question is: is it possible to guarantee that, due to the contribution, the
flow, corresponding to each user, will be
able to increase the value
of total_amount by the required value?
In fact, this at first glance is the simplest operator boils down to a sequence
of actions:
❖
Get the current value of total _ amount of global memory '
memory
❖
To increase its new _ amount and store the result in a global
memory ' memory
Consider the case where two users A and B share the same account. There
are 100 monetary units in the account. User A is going to deposit 1000 User
at the same time - 100 Flow T
A
corresponding to the user A, T flow
in
- the
user B.
Consider the following sequence of events (option 1).
1.
Stream T
A
reader mentioned total _ amount, equal to 100
2.
The stream T
B
reads the value total _ amount, also equal to 100
3.
Stream T
A
increases the read values in step 1 total _ amount in
1000, received 1100
and stores it in memory
4.
The T
B
stream increases the value of total _ amount in step 2 by
100, gets 200, and also stores it in global memory, overwriting what
the stream T
A has
saved
User A's contribution is completely lost.
Now consider another sequence of events (Option 2).
1.
Stream T
A
reads total _ amount, increase it to 1000 and records
the value 1100
in the global memory
2.
Stream T
in
reading total _ amount, equal to 1100, it increased to
100 in 1200 and writes the value into a global city
As
a result, both contributions were successfully registered.
As you can see, the result of executing the
simplest code snippet above
depends on the sequence of execution of threads in the system. This leads to
the following: in one situation the code may work, in the other - no, and in
general it is impossible to predict the occurrence of an error. This situation
is referred to
as race ( or race condition ), which is one of the most difficult
bugs captured faced by programmers. It is practically non-negotiable (since
it is unrealistic to override all possible combinations of flow execution
sequences, especially if there are many).
Attempts to bind these necessitated problems
into synchronization streams.
Immediately note that the problems of synchronization and organization of
parallel computing are some of the
most difficult in practical
programming. Therefore, the development and debugging of multithreaded
programs in particular often seen as a kind of "art" that is not known to all
programmers.
In fact, such development and debugging is not an art, but a strict
discipline, subject to one basic principle: because for multithreaded
programs, traditional debugging is not suitable, the programmer must write
the code so that at the stage of development, there is room for errors. Let us
familiarize ourselves with the rules that must be followed in order for the
generated code to comply with this principle. Consider the main approaches
to competition problems.
Sometimes (but rarely enough) you can just ignore these mistakes. This
may make sense when we are not interested in the accurate recording of
