Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

consideratuions regarding use of TMultiReadExclusiveWriteSynchronizer

john111smithjohn111smith Member Posts: 15
in the borland delphi help 2006 :

Note that a write lock operation is not atomic. Data in protected
memory will always be in a consistent state when BeginWrite returns,
but is not necessarily in the same state as when BeginWrite was
called. As a rule, a thread should always discard previous samples
from protected memory after promoting a read lock to a write lock.
However, the calling thread can determine whether a state change has
occurred by examining return value of BeginWrite: true if protected
memory has not be written to by another thread, false if another
thread may have modified protected memory.


Here, i will be appreciated with an example for Understanding the
above paragraph.


thanks in advance

Comments

  • zibadianzibadian Member Posts: 6,349
    : in the borland delphi help 2006 :
    :
    : Note that a write lock operation is not atomic. Data in protected
    : memory will always be in a consistent state when BeginWrite returns,
    : but is not necessarily in the same state as when BeginWrite was
    : called. As a rule, a thread should always discard previous samples
    : from protected memory after promoting a read lock to a write lock.
    : However, the calling thread can determine whether a state change has
    : occurred by examining return value of BeginWrite: true if protected
    : memory has not be written to by another thread, false if another
    : thread may have modified protected memory.
    :
    :
    : Here, i will be appreciated with an example for Understanding the
    : above paragraph.
    :
    :
    : thanks in advance
    :
    Suppose you have a list of 5 elements. Threads 1 & 2 are adding elements. Consider this abbreviated (for clarity) code in Thread1:
    [code]
    i := list.count;
    BeginWrite();
    j := list.count;
    [/code]
    Then i and j might be completely different. This is what the computer might be doing:
    [code]
    Thread1: i := list.count; // i = 5
    Thread1: BeginWrite().statement 1
    Thread1: BeginWrite().statement 2
    Thread2: list.add(newElement);
    Thread1: BeginWrite().statement 3
    Thread1: BeginWrite().statement 4
    Thread2: list.add(newElement);
    Thread1: BeginWrite().statement 5
    j := list.count; // j = 7
    [/code]
    Here BeginWrite().statement indicates a single statement in the BeginWrite() method.

    I left out a number of declarations and generalized names for clarity and readability.
  • john111smithjohn111smith Member Posts: 15
    : : in the borland delphi help 2006 :
    : :
    : : Note that a write lock operation is not atomic. Data in protected
    : : memory will always be in a consistent state when BeginWrite returns,
    : : but is not necessarily in the same state as when BeginWrite was
    : : called. As a rule, a thread should always discard previous samples
    : : from protected memory after promoting a read lock to a write lock.
    : : However, the calling thread can determine whether a state change has
    : : occurred by examining return value of BeginWrite: true if protected
    : : memory has not be written to by another thread, false if another
    : : thread may have modified protected memory.
    : :
    : :
    : : Here, i will be appreciated with an example for Understanding the
    : : above paragraph.
    : :
    : :
    : : thanks in advance
    : :
    : Suppose you have a list of 5 elements. Threads 1 & 2 are adding
    : elements. Consider this abbreviated (for clarity) code in Thread1:
    : [code]:
    : i := list.count;
    : BeginWrite();
    : j := list.count;
    : [/code]:
    : Then i and j might be completely different. This is what the
    : computer might be doing:
    : [code]:
    : Thread1: i := list.count; // i = 5
    : Thread1: BeginWrite().statement 1
    : Thread1: BeginWrite().statement 2
    : Thread2: list.add(newElement);
    : Thread1: BeginWrite().statement 3
    : Thread1: BeginWrite().statement 4
    : Thread2: list.add(newElement);
    : Thread1: BeginWrite().statement 5
    : j := list.count; // j = 7
    : [/code]:
    : Here BeginWrite().statement indicates a single statement in the
    : BeginWrite() method.
    :
    : I left out a number of declarations and generalized names for
    : clarity and readability.

    tanx,
    this is a natural behaviour of a multitask application and it was not necessary that borland describe such an obvious situation!
  • zibadianzibadian Member Posts: 6,349
    : : : in the borland delphi help 2006 :
    : : :
    : : : Note that a write lock operation is not atomic. Data in protected
    : : : memory will always be in a consistent state when BeginWrite returns,
    : : : but is not necessarily in the same state as when BeginWrite was
    : : : called. As a rule, a thread should always discard previous samples
    : : : from protected memory after promoting a read lock to a write lock.
    : : : However, the calling thread can determine whether a state change has
    : : : occurred by examining return value of BeginWrite: true if protected
    : : : memory has not be written to by another thread, false if another
    : : : thread may have modified protected memory.
    : : :
    : : :
    : : : Here, i will be appreciated with an example for Understanding the
    : : : above paragraph.
    : : :
    : : :
    : : : thanks in advance
    : : :
    : : Suppose you have a list of 5 elements. Threads 1 & 2 are adding
    : : elements. Consider this abbreviated (for clarity) code in Thread1:
    : : [code]: :
    : : i := list.count;
    : : BeginWrite();
    : : j := list.count;
    : : [/code]: :
    : : Then i and j might be completely different. This is what the
    : : computer might be doing:
    : : [code]: :
    : : Thread1: i := list.count; // i = 5
    : : Thread1: BeginWrite().statement 1
    : : Thread1: BeginWrite().statement 2
    : : Thread2: list.add(newElement);
    : : Thread1: BeginWrite().statement 3
    : : Thread1: BeginWrite().statement 4
    : : Thread2: list.add(newElement);
    : : Thread1: BeginWrite().statement 5
    : : j := list.count; // j = 7
    : : [/code]: :
    : : Here BeginWrite().statement indicates a single statement in the
    : : BeginWrite() method.
    : :
    : : I left out a number of declarations and generalized names for
    : : clarity and readability.
    :
    : tanx,
    : this is a natural behaviour of a multitask application and it was
    : not necessary that borland describe such an obvious situation!

    This behaviour is highly implementation dependent. It is possible to implement BeginWrite() as an atomic entity. This makes the description in the help file quite important, especially the first line. The specification also describes the memory state of the protected memory, which is also quite important for programmers.
  • john111smithjohn111smith Member Posts: 15
    tanx again for attention.
Sign In or Register to comment.