David, On Mon, Oct 31, 2016 at 11:34 PM, David Adams <dpad...@gmail.com> wrote:
> > Can you write an example db that does this? > Probably, I've seen it done in the past. Would I now? No, I wouldn't bother > trying. Unless 4D *guarantees* the non-standard behavior you're hoping to > exploit, it's risky at best. They don't offer any such reassurance. Also, I > pretty rarely used IP arrays for shared objects for much of anything...I > just don't have a lot of situations where that's the best solution. > I think the example I provided establishes the sort of situation you describe. I mean - 400 processes simultaneously writing to the same variable for 2 seconds. As I understand it a race condition develops when there is a sequencing issue - the value Process A will write depends on a value Process B already wrote. I'm not talking about that either. In this test I don't care what order the elements are written in (I had to add inconsistency to the delay periods to force it out of sequence in the first place) or what the value is - just whether it would be written correctly. Adding the lock wouldn't prevent that in this case either. If sequence were important you would need to address it but that wasn't the question I was looking at. As I mentioned before I didn't look at changing multiple vars at the same time. So if I have 4 arrays that needed to be updated at the same time the situation could be different. There's more variability in this case and setting the lock makes sense. And I'm not sure 4D guarantees anything. I'm loath too. Buried within pretty much everyone's EULA is something to the effect of, "we think this works pretty well but it's up to you to decide if you trust it or not because we can't guarantee it actually does anything." I may be paraphrasing. I'm old enough to avoid saying 'never' any more but I'm still a sucker for strong evidence. > > And bear in mind I'm talking about conditions on a client - not the > > server. > Doesn't matter. It's a multi-process machine, either way. > True, but this illustrates that without multi-threading it's still a sequential processor. Only one process at a time can be executing. > > And I'm not talking about situations where an external client might be > > attempting to set variables either. > You mean SET PROCESS VARIABLE, etc.? I forgot about those. I never use > > them. Me either. I prefer writing records to a messaging table instead. An idea I believe I got from you. But in this case I suspect the result would be the same - that 4D doesn't actually execute multiple processes simultaneously. The buried lede in this story may actually be how easily 4D handles 400 simultaneous processes. -- Kirk Brooks San Francisco, CA ======================= ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
