p2psim loctable

p2psim loctable is the location table storing routing information, for chord finger protocol, it stores the address info for 2^{i} long-range links, refer to ChordFinger::initstate()

p2psim question

p2psim is actually single threaded -- you almost never have to worry
about locking.  There is only ever one thread running at a time.  The
only time you have to worry is the persistance of variable state across
a doRPC call.  When you do a synchronous RPC, p2psim will probably allow
other threads to run, and it's possible those threads can change shared
state such that when the RPC finishes and control returns, you might
have unexpected consequences (e.g., the node has died in the meantime). 
So just be careful that when you come back from an RPC, you check for
any assumptions that may have been violated.

ConditionVar is a method for threads to sleep until some specific event
happens in another thread.  For example, in Tapestry, we use it to pause
events that arrive while the node is in an unjoined state.  When the
join completes, those events are notified via the ConditionVar, and they
continue to be processed.  It is not too useful for synchronization, but
again, there is no need for synchronization in p2psim anyway.

p2psimulator design guide

http://fada.sourceforge.net/p2psim/design.html

synchronization mechanism in linux

Linux supports the following synchronization mechanisms:

• Critical Section A critical section is a piece of code that may be accessed only by a single thread at a time, for example a code segment that changes a shared variable.

• Mutual Exclusion A mutual exclusion (mutex for short) is an object that restricts access to a variable or code section to a single thread at a time. Thus, you may use a mutex to protect a critical code section.

• Semaphores A semaphore restricts access to a variable or object to a limited number of threads. For example, a semaphore may be used to ensure that three threads at most access a system's clock.

the concurrency control

the transaction issue comes:
when overflow or underflow happens, block data need to be created or destroyed, while the query/update request are kept forwarding to those blocks, so before the stablization of a new block (split-out or merged-into), the block interconnection will not be modified, neither the data in the block. queries including update has to be queued and been synchronized to the stablilized block.

p2psim

1. needs to use one's own loctable to precise locate predecessor/successor
2. _max_lookup_time need to be taken care of

timing

no transaction, the message forwarding can be screwed
must be careful of the timing of the message ni discrete event simulator
I need to put things I impose order on in the event queue in sequence

transaction control

block structure contains two sub structures: index_block and catalog
operations for both contain query and update(insert / delete)
transaction control needed!