Ticket #2431: interprocess.patch

File interprocess.patch, 2.7 KB (added by Charles Brockman <cmbrockman@…>, 14 years ago)

Patch for the Interprocess Documentation

  • libs/interprocess/doc/interprocess.qbk

     
    15161516can do two things:
    15171517
    15181518*  [*wait]: The thread is blocked until some other thread notifies that it can
    1519    continue because the condition that lead to waiting has disapeared.
     1519   continue because the condition that lead to waiting has disappeared.
    15201520
    15211521*  [*notify]: The thread sends a signal to one blocked thread or to all blocked
    15221522   threads to tell them that they the condition that provoked their wait has
    1523    disapeared.
     1523   disappeared.
    15241524
    15251525Waiting in a condition variable is always associated with a mutex.
    15261526The mutex must be locked prior to waiting on the condition. When waiting
     
    21782178A lock transfer operations explicitly indicates that a mutex owned by a lock is
    21792179transferred to another lock executing atomic unlocking plus locking operations.
    21802180
    2181 [section:lock_trnasfer_simple_transfer Simple Lock Transfer]
     2181[section:lock_transfer_simple_transfer Simple Lock Transfer]
    21822182
    21832183Imagine that a thread modifies some data in the beginning but after that, it has to
    21842184just read it in a long time. The code can acquire the exclusive lock, modify the data
     
    36683668As mentioned, the managed segment stores the information about named and unique
    36693669objects in two indexes. Depending on the type of those indexes, the index must
    36703670reallocate some auxiliary structures when new named or unique allocations are made.
    3671 For some indexes, if the user knows how many maned or unique objects is going to
    3672 create it's possible to preallocate some structures to obtain much better
    3673 performance (if the index is an ordered vector it can  preallocate memory to avoid
    3674 reallocations, if the index is a hash structure it can preallocate the bucket array...).
     3671For some indexes, if the user knows how many named or unique objects are going to
     3672be created, it's possible to preallocate some structures to obtain much better
     3673performance. (If the index is an ordered vector it can  preallocate memory to avoid
     3674reallocations. If the index is a hash structure it can preallocate the bucket array.)
    36753675
    36763676The following functions reserve memory to make the subsequent allocation of
    36773677named or unique objects more efficient. These functions are only useful for
     
    56715671[section:basic_guidelines Basic guidelines]
    56725672
    56735673When building [*Boost.Interprocess] architecture, I took some basic guidelines that can be
    5674 resumed in these points:
     5674summarized by these points:
    56755675
    56765676*  [*Boost.Interprocess] should be portable at least in UNIX and Windows systems. That
    56775677   means unifying not only interfaces but also behaviour. This is why