Sometimes we're dealing with a lot of high fallutin' AI-esque algorithms and lose sight of the basics. In this case no special handling, just socket messaging, events and timers.
~PM Date: Sun, 8 Mar 2015 20:55:17 -0400 Subject: Re: [agi] Psyche semaphore... From: [email protected] To: [email protected] 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 | Modify Your Subscription AGI | Archives | Modify Your Subscription ------------------------------------------- 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
