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
Ok...so are you suggesting that, for example, I write a StoreProperty wrapper procedure which first Fetches an item named "propertyList" (using itoo.FecthProperty) adds the item name (being stored) to the list (if not already on in the list) and then StoreProperty the named item as well as the possibly modified list?
And then when I want a list of properties that have been stored, I simply FetchProperty (propertyList)?
Can I use the broadcast block from a foreground service process to kick off a broadcast so that the assigned function gets run? In other words, is broadcast block only meant to be called from the UI thread, or is it OK to call from a foreground service process as well?
In short, I am trying to use broadcasts to kick off a function running asynchronously, so that it doesn't hold up the foreground service where it's being called from.
Edit: ran a quick test with Itoo 4.1. I can sucessfully kick off the registered procedure when I use the broadcast block from a UI thread (like a button press), but I can't seem to trigger a broadcast from inside of the foreground process/service. Is this by design?
Hello @aeozyalcin the broadcast block should while called both inside the app and outside the app (in the services).
When it is called from services, the application will receive it in BroadcastReceived event block.
When it is called from the app, services can listen to a particular broadcast event by registering a procedure. Using RegisterBroadcast block. That paricular procedure will be called with an argument when a broadcast is received.
Thank you @Kumaraswamy! I have made this quick test project to convey what I am observing with the broadcast blocks. When the broadcast block gets called from the UI (i.e. button press), it runs as I would expect - I get a notification saying it was triggered by a button press.
However, there is also a 2 second timer active, that is making the same broadcast every time it ticks. To confirm it's ticking, it sends a separate notification each time it ticks, before making a broadcast. However, I never get the notification from the registered broadcast procedure saying it was kicked off from the timer tick. I have included the sample project below. Is what I am observing the expected behavior? Am I missing something?
Edit: I just tested the same project with Itoo v3, and it works like I expect it to! I am getting the notifications saying it was triggered from the clock tick function. So there is different behavior between v3 and v4.1.
Hello @aeozyalcin, I checked the AIA that you posted, that included Version 1.4 and it worked as it should.
I believe you are misunderstanding the broadcast concept here. You are thinking that whenever the service sends a notification, it will also trigger the testBroadcast_fxn.
But this is wrong, when one broadcast is created from service, only the UI can receive it. Service cannot read it's own message.
If a broadcast is created in service ---> only UI can listen to it
If a broadcast is created by UI --> Only the service can listen to it
Thanks @Kumaraswamy! 2 follow up questions for you:
When I swap Itoo v4.1 for v3 on the test project, I see that test_clk_fxn is able to trigger testBroadcast_fxn. Any ideas why the behavior is different between the versions?
Thank you for clarifying that service threads aren't meant to trigger a broadcast that was registered by the service. This is how I was kicking off a procedure asynchronously/on a different thread without holding up my main service thread back in v3. Do you have any recommendations on how I should go about that with v4.1? Maybe createTask?
Thank you! I clearly misunderstood broadcasts; I appreciate you explaining. Leaving broadcasts aside, do you have any hints/recommendations on how I can achieve multithreading such that I can have a function run on another thread without blocking the originating thread?
An example of what I am trying to do: I have a timer tick event that Itoo listens for. I want to make sure that the timer tick callback function can finish quickly, so that it's ready for the next clock tick. To achieve this, ideally, I want to spawn off function calls from inside this callback to run on other threads, so I am not holding up the clock tick callback procedure.
I understand what you want to achive
With the current system in place, this is not possible.
Few months ago, I was experimenting with a Automatic Async extension that lets you easily manage and dynamically spawn many threads, however it was not released.
Alternatively, you can use AsyncProcedure extension written by Ewpatton, that lets you call procedures on a different thread.
