Re: concurrency + threads + synchronization

On Jul 30, 4:21 pm, Peter Boettcher <boettc...@xxxxxxxxxx> wrote:
Ginu <osheik...@xxxxxxxxx> writes:
On Jul 30, 1:13 pm, Peter Boettcher <boettc...@xxxxxxxxxx> wrote:
Ginu <osheik...@xxxxxxxxx> writes:
Simulating simultaneous events does not require actually computing them
simultaneously.  And I would advise against it!  What happens when you
want to simulate 1,000,000 nodes?  You certainly don't want 1,000,000
threads on your computer, but might be happy with the simulation taking
much longer to compute.

Basically, you store the current "simulation time", and each event
carries along a field which says when it should be processed, in
simulation time.  Loop through each node in sequence.  If there is an
event to process, or state to update, do it.  If, as you mention, you
need to maintain consistency of state of nodes with relation to each
other, then store each new node state into a "new state" structure.
Then when the entire time step is finished, advance all the states at
once.

This way, the simulation runs as fast or as slow as the computer can
handle.  Time values are exact in simulation time.  Etc.

Does this approach make sense?

-Peter- Hide quoted text -

- Show quoted text -

Ya it does. The only issue is that, because this network is wireless,
there's an issue of interference. Each event that needs to be serviced
in an iteration involves a transmission which is affected by the
current level of interference at that node. The interference
calculation is the protected code that I want to synchronize around.

With your approach, would I update the interference at the end of a
single transmission, or are you suggesting that I wait until all nodes
are serviced for a single iteration and then update the interference
at the end of the iteration? Which way would more naturally mimick
concurrency?

It depends on what best models your system, and how detailed your model
is.  Probably calculate all the interference for all the nodes, then
update them all at once.  That way all nodes use the interference which
is EXACT at the simulation time in question, then update their
interference numbers for the next time step.  That's very concurrent.

But is it detailed enough?  That's up to you.  If transactions at the
same point in time can affect all the nodes at that same point in time,
you have a very difficult coupled problem to solve.  Or you could just
reduce your simulation stepsize so that you can model it AS IF each node
depended only on interference from nodes at the previous time step.

Actual compute threading is not going to help you with this, since none
of these issues go away.

-Peter- Hide quoted text -

- Show quoted text -

Transmissions starting at the same time affect all nodes'
interference, but since there is no interference maximum, this will
reduce the active rate for the next iteration of these transmissions,
which isn't a problem. The problem arises because of the fact that
transmit power is a concern in wireless networks, i.e. all
transmissions in wireless settings require a node to use their limited
battery power and dissipate this power in a transmission. The reason
that concurrency is so important is that I would have been able to
protect certain code, in this case code for updating remaining battery
power based on power dissipation. Without concurrency, I now run the
risk of running into a problem where the same node gets used in two or
more transmissions (because at the start of that iteration its battery
power sufficed). Now, because I cannot protect the code that would
have kept battery power consistent for a particular thread (that would
have kept other threads queued up waiting until this information
became available again), if that same node gets used in two or more
transmissions, I run the risk of the sum of the power dissipated at a
node is greater than the power available to that node over those
transmissions. If that makes sense. Interference can be modeled at the
end of the iteration, but a way needs to be found to update the
battery power to keep it "honest". It is possible that I can update
interference at the end of the iteration, but update battery power as
I use it while servicing each node each iteration one by one.
.

Relevant Pages

  • Re: concurrency + threads + synchronization
    ...  Probably calculate all the interference for all the nodes, ... transmissions in wireless settings require a node to use their limited ... battery power and dissipate this power in a transmission. ...
    (comp.soft-sys.matlab)
  • Re: concurrency + threads + synchronization
    ...  Probably calculate all the interference for all the nodes, ... Transmissions starting at the same time affect all nodes' ... battery power and dissipate this power in a transmission. ...
    (comp.soft-sys.matlab)
  • Re: concurrency + threads + synchronization
    ...  Probably calculate all the interference for all the nodes, ... transmissions in wireless settings require a node to use their limited ... battery power and dissipate this power in a transmission. ...
    (comp.soft-sys.matlab)
  • Re: Standing-Wave Current vs Traveling-Wave Current
    ... line through a source resistor equal to Z0, ... would be creating power unless the cosis negative. ... It means that some excess amount of destructive interference ... The reflection from a surface should create standing waves in LOCAL space that will contain double the power of open ...
    (rec.radio.amateur.antenna)
  • Re: Remote control central locking systems.
    ... >> So the question is what can cause this apparent localised interference ... but not my older car? ... and also by relatively high power users ... Type of Transmission ...
    (uk.rec.cars.misc)