On Nov 1, 2016, at 2:00 PM, Bernd Fröhlich wrote: > Kirk Brooks wrote: > >> True, but this illustrates that without multi-threading it's still a >> sequential processor. Only one process at a time can be executing. > > Yes, BUT... > > The thing about semaphores is, that they are atomic commands (the command is > guranteed to execute without any other process interrupting it). > And semaphore is the ONLY atomic command, all the other commands can be split > in the middle by the systems scheduler.
I’m not sure I agree that the ONLY 4D command in the language that is atomic is “Semaphore”. I’m guessing there are others. Gonna need a 4D engineer like Laurent Esnault that knows the deep internals of 4D’s code to know for sure. > Your example might work, as you are only adding to the array but it will > break, when you also delete array elements. > Consider this: > > Process A adds array elements to an IP array and Process B deletes elements. > Works fine, as long as the scheduler does not interrupt one of those commands. > > If the array has zero elements and process A tries to create a new one, the > sheduler might switch processes when the element is created, but before a > value is assigned. > Then process B deletes an element. > Now if it´s processes A time to continue, it tries to write the value to an > array element that does not exist anymore. BAD! > > That´s why you better protect access to IP arrays/variables with semaphores. > > It is very hard to simulate the above since lots of conditions come into play > and you MIGHT get lucky that it never happens to you, but if it DOES happen - > good luck with finding the error. The rule that I have always followed is there is no need to protect simple IP variables like real, longint, text, etc. I can’t see how reading or writing to a single, simple IP variable could cause any issues with multiple processes. I treat IP arrays differently because usually when you are manipulating an array there are multiple step involved in getting and setting values in the array. You may have to check the array size first, then you APPEND TO ARRAY or INSERT IN ARRAY. Or you do a "Find in array” and then you read or write an element in the array. The point is the read or write to the array requires more than 1 line of 4D code, and I am working under the assumption that a single line of 4D code will run atomically. Just think of the problems if “<>counter_l := <>counter_l + 1” were to be interrupted in the middle of execution. First you get the value of <>counter_l, then there is a context switch and another process changes <>counter_l, then your process resumes and it takes its own <>counter_l value it had before the context switch, adds 1, and then stores the result in <>counter_l. I might be wrong about “one line of 4D code runs atomically”. But and again you need somebody like Laurent Esnault — maybe Miyako or Thomas Maul knows — to tell you how the interpreter works. And also how the 4D compiler works. Could be compiled code acts a bit differently that interpreted at this super low level. So if I am going to work on an IP array, I protect that block of code with a semaphore. And of course if I are dealing with a group of related IP arrays it’s absolutely critical to protect them with a semaphore. You want all the operations on all the IP arrays in the group to take place as a single action. There are too many chances for a context switch with so many lines of code. I think Kirk was asking about the “<>counter_l := <>counter_l + 1” example not IP array updates. I see no reason to protect simple IP variables that are just getting a value set or retrieving a value. IP arrays are another story and the code block does need to be protected with a semaphore. Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ******************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
