If a thread, for example, created other threads as it tried to solve some problem, then the little o problem could become a big o problem. But it did not sound like that was the situation that was being described.
Jim Bromer On Sun, Mar 8, 2015 at 8:49 PM, Jim Bromer <[email protected]> wrote: > Microsoft .net has events that can be posted which will be read by another > part of the code (including but not necessarily other threads). I cannot > remember just how it is executed but I remember from long ago that the > modern processors all have many exception processes which means that code > can be interrupted in order to do something with 'external' (virtual or > actual -peripheral or software) data. So a semaphore reading loop should > not be absolutely necessary. However, most programs use some kind of loop > and even if data is sent through an event in .net, I just used the event > type data (the type of event that I defined) to fill in a variable in the > other thread which was then read in a loop that examined the variable along > with other variables. The problem is that even if you found an event-like > method (or a software exception-like thing) the demand that the timer loop > exit gracefully almost means that it will definitely need to stay within > its main program loop. If you found an event-like action that you could use > you might set the timer to 0 or something like that and let it exit > according to the timer=0 plan or something. That would allow the program to > react without checking some kind of event variable. However, you probably > have to ask the java people about that. > > I don't like simple software switches that have to be read over and over > again until they are set when they are only set once. However, modern > processors don't recommend that the programmer uses dynamic code. It would > be fairly easy to use dynamic code (with C++) to change the execution > code if that was something that really was important. So the program > follows one code path until the condition occurs in which case the > execution code is changed a little. Stick in a new branch or something like > that. With C++ and all the layers that we have between us and the machine > code you would have to use different pieces of code like different function > calls. But again, unless that was part of the fundamental nature of how > your program is going to work, all the little function calls that you need > only to be able to deal with the condition then adds extra jumps between > the function particles. So it is really the same thing - there is going to > be some extra little stuff in the code just to deal with the occasional > conditional - unless you want to use a bunch of really small functions that > are strung together anyway. You could do that in java but is it really > going to make your program more efficient. > > Anyway, does it make sense for you to worry about details like little o > stuff? > > Jim Bromer > > On Sun, Mar 8, 2015 at 4:46 AM, Piaget Modeler via AGI <[email protected]> > wrote: > >> I'm working on a Psyche application this week which interacts with a >> device >> on behalf of an AI "mind". Here's a proposed call tree diagram. What >> do you think? >> >> Terminated is a boolean semaphore object that tells the timers that the >> program is >> done, and that the timers should terminate gracefully. An event will set >> the >> Terminated semaphore object to True. >> >> The only problem is that the semaphore will be continually read by all >> the timers >> when determining whether to exit their timer loop. Is there a better >> way? >> >> Your thoughts? >> >> ~PM >> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> >> <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | >> Modify >> <https://www.listbox.com/member/?&;> >> Your Subscription <http://www.listbox.com> >> > > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
