Picture of Wim 4127
Registered 6 years 310 days
Wim 4127 Wednesday, 3 June 2020, 03:23 PM
Is an app multithreaded?
Apps are implemented "asynchronous" by using the different tasks and alike (~iomux). However, this does not explain everything about the threading used or not used:
- Suppose I launch two tasks immediately after each other, will they get queued and handled one after the other?
- What is the effect on the callbacks? Are the callbacks all done with the same thread, and, is this the same thread as when the app is started? Or, in other words, is an app single threaded? Or multi-threaded and are the callbacks launched from different threads?

Since I haven't seen any thread safety structures in any sample code, may I presume an app is completely single threaded at all times?
Picture of Daniel Deterding (innovaphone)
Moderator Registered 15 years 179 days
Daniel Deterding (innovaphone) Thursday, 4 June 2020, 08:18 AM
1 of 1 users consider this post helpful
Re: Is an app multithreaded?
All callbacks within the iomux context are executed on your main thread.
So yes, an App is single threaded, as long as you do not implement own threads for certain stuff.

Some libraries which we are using are also using own threads and they use thread safety structures in their implementation to queue iomux callbacks into the main thread (e.g. you need to call iomux->SetExecLocked, if you are not inside your main thread, but want to talk to it).

If you start two task one after the other, it doesn't mean that the task execution itself is queued. It depends on what your task does.

Example:

Task1 is of UWebserverGet
Task2 is of UDatabase

you call Task1->Start which itself calls IWebserverGet::Send to send a packet as an answer to a GET request, Task1 leaves the Start function and does nothing anymore
you call Task2->Start directly afterwards which calls IDatabase->ExecSQL to issue a query, Task2 leaves the Start function and does nothing anymore

Task1 is now waiting for the UWebserverGet::WebserverGetSendResult callback.
Task2 is now waiting for the UDatabase::ExecSQLResult callback.
Your app now does nothing anymore and the iomux hangs inside its epoll_wait function which is triggered on file descriptor actions.

The task callbacks are triggered within the iomux when the sockets of the database and/or the webserver are responding to your previous actions.
This now depends on which socket answers faster to which action.
So it could be that Task1::WebserverGetSendResult is called before Task2::ExecSQLResult or the other way round.

Greetings,
Daniel
← You can define your color theme preference here