Here is an illustration of the kind of "parallel/concurrent" access that I want to be able to do - without collision between the user interface and the service.
Two timers: one running in the visible user interface and another in the itto service. Each is incrementing its own count as well as a shared count.
If there were no shared count interference - i.e., if each reads, increments, and writes the shared count without the other intervening with its identical operations, then the sum of the individual counts would be equal to the shared count...which it is initially. However, eventually, it is not.
Open the app, then press start. Open the app again and use the button to check the counts periodically.
I know this is only a toy - with no useful function - except to illustrate the kind of exclusive access I am speaking of.
Hmm, I took a look into that. This is a race condition, which leads to inconsistent data outcomes.
Itoo's Service runs on a different process than that of the app, so they will always remain non-synced.
From what I understand, you need a mechanism where the write/read is done safely. Meaning when the data is being read/write, no other process should do the same. Thus avoiding data inconsistency.
This would require us to create a "lock" mechanism, similar to that offered by Java, where a particular block of code, even called by many different processes, execute in order-of-call.
Did I understand that correctly, what you were trying to convey me? Then please reply yes.
Also, if you are interested, you can sponsor a new extension for $15 (I'll try to solve this race condition issue)
This could be as simple (though potentially inefficient) as a semaphore - where each thread requests the "lock" asynchronously until it is acquired and release it when done.
Or it could be more sophisticated and, for example, queue access requests and grant them in order of request, granting each subsequent request when access is released.
If none exists in appinventor, then this could be a very useful extension.
I am a little surprised that I find little/no mention of this in the forum (maybe I missed it). It makes me wonder if, for some reason, such a lock was not needed or would not be useful or practical or maybe even not possible.
You didnt miss it, in App Inventor, there wasant such a complexity to deal with before. App Inventor apps' blocks are single threaded, everything runs on a single thread.
Meaning internally the components may utilize multi threading capabilities, but with a block coder's perspective, there really isnt a way to multi thread on App Inventor.
Race conditions often occur when two different processes/threads try to read and change the same data on the same location. (This issue never arose in App Inventor).
(I am using the word "thread' and "process" inter-changeably here)
It would seem that the basic test-and-set (semaphore) lock functionality could implemented using the: intgetAndSet(int newValue)
method from the AtomicInteger class
Each process/thread wanting access calls getAndSet (1) until it returns a '0'...every subsequent call from a process/thread will be returned a '1'.
Then after performing the protected operation(s), the '1' is reset to a '0' by the process with access by calling getAndSet(0), making it (the '0') available to other process(es)/thread(s).
The '0' is the permission token. It only exists in one place - either in the integer object (as when it is first created) or in a process which obtained it by getAndSet(1), replacing the '0' with a '1' in the object.
In cases where a collision is unlikely and/or the processing to be protected is of short duration (I believe this is true in my use case), the getAndSet(1) maybe done repeatedly ("spin on the lock") since access would likely be granted quickly.
The extension could simply be an "AccessToken" with GetAccess and ReleaseAccess methods which would do the underlying getAndSet calls. Or it could possibly be incorporated into the itoo extension(?).
One problem I see is that a thread/process could not be allowed to die/crash/exit while in possession of the '0', thereby causing any other process/thread calling getAndSet(1) to "hang"... perhaps some sort of timeout could be implemented...
... just "thinking out loud"... "for what it's worth" (excuse the English idioms )
Ok. I can see that what I had in mind using AtomicInteger is not possible in the normal sense of its use...
Let me return to a request in my earlier post:
I want to understand the itoo broadcast mechanism. I'd like to send messages both ways: from foreground UI to the itoo registered service and from the service to the UI, both in the same app.
Can you point me to example code that might help me understand how this broadcast messaging works?
Hi, one of the examples showcasing Broadcasting abilities is my music player guide:
Although please note that the version used in the above project is older than the present version. Though the working is almost same.
Or let me try to explain how you'll implement it.
Case1: Send a message from UI to background?
For that, you use the RegisterBroadcast block in the the background, along with arguments "name" and a "procedure". What happens when that particular broadcast "name" is triggered? It will call that "procedure" with one argument, i.e the message.
Then you'll use the Broadcast block, in the UI, along with the name and the message.
Case2: Send a message from background to UI
In the background, similarly, directly, use the Broadcast block, along with the name and the message.
In the UI, there is an event block called BroadcastEvent that triggers whenever a new message is received.
Thanks, very much for your example and explanation (I might suggest that you add the explanation the next time you update the documentation
Can both cases be used in the same app so that messages may go in both directions (to/from service)? Or is it one direction only: Case1 OR Case2 in a single app?
If bi-directional is possible, then must the message "names" be distinct/different or could they be the same?
I think I may have solved my problem - needing to protect itoo property data from "simultaneous" access by different threads/processes. (If not, then at least I think I may have found a use for the GetAndSet() function which WOULD provide protection)
Here is the proposed solution where user interface processing and service processing must be protected from simultaneous access:
Each processing is placed in its own procedure (UiProcessing and ServiceProcessing).
When the UI processing is to be done, an itoo.Broadcast (named, say, "UiMsg") is sent.
The Service registers the UiProcessing procedure to execute on message receipt (RegisterBroadcast) of UiMsg. Any arguments needed for this procedure could be contained in the message itself.
When protected processing from the service is to be done, it simply calls ServiceProcessing.
This way the Ui and Service processing procedures execute in the same thread (the service), and no further lock/protection is required. If they somehow execute in different threads (here I confess my ignorance of just how this works), then the GetAndSet() function could provide the required protection.
I have modified my earlier test case to work in this manner, showing where the get and release access calls would go - if needed. What do you think?
You will note that, while the incrementing of the counts is protected, the reading of them for display by the UI is NOT... I am working on a change so that the read of the counts is also done in the service (on receipt of a message from the UI) and then the service sends these counts to the UI for display using Broadcast to the UI BroadcastEvent.
If you display enough times you will likely note invalid display results. For example, I have seen "-7" for service count which is the "if not there" entry for FetchProperty of the service count.
I am posting the update which does a safe display of the counts.
Because the counts are now read by the service, the service must be running (tap Start) before any counts will be displayed (Restart app after starting service to display counts.).
I am using the itoo persistent property feature (StoreProperty, FetchProperty) and find that I want to display (at least for debug purposes) the value of each named property which has been stored. As I search through my blocks for ".StoreProperty" so as to build a list of them through which to iterate and log/display, the thought occurred to me that if there were an itoo.GetPropertyList block, it would be very useful
)
Itoo's 2nd Anniversary
