 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Math Forum / Math Software / MATLAB / July 2008concurrency + threads + synchronization
Hi everyone, I have a network that I'm simulation in Matlab. Each node in the network has events arriving at any time. Instead of using a timer object which does not allow triggers at irregular intervals, I've created a 'timer' through checking through iterations of an endless 'while' loop. So now that I've gotten the background out of the way, I'm going to be having several events occuring at any one iteration of my while loop - events that would be considered 'concurrent' in reality, i.e. all nodes are independent and should be processing these events at the same time. This raises some important questions: 1) Can I create a separate thread for each node that needs to concurrently process an event each iteration? 2) Is there a way to protect certain parts of code to maintain consistency of data through synchronization? i.e. I don't want certain nodes changing data right in the middle of a calculation. Thanks in advance, Omar > Hi everyone, > [quoted text clipped - 19 lines] > Thanks in advance, > Omar I forgot to mention, the tasks that I need each thread to perform don't necessarily have to be in a callback function. If a callback function is required for threading, then I can adapt my code. > > Hi everyone, > [quoted text clipped - 25 lines] > > - Show quoted text - nobody? >> Hi everyone, >> [quoted text clipped - 23 lines] > don't necessarily have to be in a callback function. If a callback > function is required for threading, then I can adapt my code. 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 > >> Hi everyone, > [quoted text clipped - 47 lines] > > - 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? Thanks in advance. >> Simulating simultaneous events does not require actually computing them >> simultaneously. And I would advise against it! What happens when you [quoted text clipped - 31 lines] > 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 > >> Simulating simultaneous events does not require actually computing them > >> simultaneously. And I would advise against it! What happens when you [quoted text clipped - 50 lines] > > - 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. >> It depends on what best models your system, and how detailed your model >> is. Probably calculate all the interference for all the nodes, then [quoted text clipped - 34 lines] > interference at the end of the iteration, but update battery power as > I use it while servicing each node each iteration one by one. This is the fun of modelling. Like I say, computing concurrence just makes this worse. Figure out the right approximation for processing the nodes in sequence, but simulating concurrency. You could even use multiple passes through all the nodes for a single time step. I don't quite understand how multiple transmissions happen at one node at the same time. If they really ARE at exactly the same time, then they share the battery usage, so you can do the transmissions, then update power. If they are not at the same time, then you need a finer simulation time-step. -Peter > >> It depends on what best models your system, and how detailed your model > >> is. Probably calculate all the interference for all the nodes, then [quoted text clipped - 49 lines] > > - Show quoted text - The reason multiple transmissions happen at one node is because a transmission involves sending data from source to destination across multiple hops, so while a node, say 5, is part of a path like below, for example [ 1 2 5 10 100] where it's the 3rd hop along the path from node 1 to node 100, node 5 might still have its own event arriving at this same time instant. Transmissions can occur at the same time because different transmissions can use different frequencies (without getting too much into the nitty gritty of wireless transmission) and a node can send over multiple frequencies simultaneously. > >> It depends on what best models your system, and how detailed your model > >> is. Probably calculate all the interference for all the nodes, then [quoted text clipped - 49 lines] > > - Show quoted text - With what I said above, I think I've decided to update power when servicing a node, and interference at the end of each iteration, because, in reality, two transmissions rarely start at the EXACT same moment and so there will be some small time period where these transmissions don't overlap. Thus, I can update the remaining power of these nodes after servicing their events individually (because the power would be affected instantaneously), while updating the interference at the end (because interference isn't instantaneous - the transmission would have to travel distances first to cause interference at another node). |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.