Automation implementation using Busy Waiting or Threads in c++ - visual-c++

I am trying to automate the handler equipment(a robot picks a chip and put it onto a hardware platform) with the following requirement:
1.There are 6 sites for the handler , once handler puts a device onto that site, handler will return an errorcode:
code1 for ready to test, code2 for error, and if in process no code have returned.
2.There is a master PC that controls the handler operation, and the communication b/w master and site PCs are using Staf
3.I need to use that code to run some tests(which already implemented and working properly).
Handler puts the device in a FIFO order, first site returns code first, and last site returns code last.
4.The Site PC is acting passively, which master PC will determine when to run and how to run the tests. Site PC will only know if handler is ready then execute the tests.
So my question would be: In this case, for the site-PCs(Windows based with perl and .net enabled), is busy waiting method better or is the wait condition mechanism suits better:
For example: the sample code would be:
void runTestonSite()
{
for(;;)
{
if(returnCode == code1)
{
testStart(arg1,arg2,arg3);
}
}
}
or is there any better way to do this kind of task?
#include <boost/thread.hpp>
void getReturnCode() {
// do stuff
}
void RunTestOnSite() {
// do stuff
}
int main (int argc, char ** argv) {
using namespace boost;
thread thread_1 = thread(getReturnCode);
thread thread_2 = thread(RunTestOnSite);
// do other stuff
thread_2.join();
thread_1.join();
return 0;
}
Please advise,
thanks

Related

Glib: Calling a iterative loop function

Have a query on timeout calling and GMainContext. It is really confusing to me
Suppose I have the codes below (a bit incomplete, just for demonstration). I use normal Pthreads to create a thread. Within the thread, I run Glib functionality and created a GMainContext (stored within l_app.context).
I then created a source to run the function check_cmd iteratively at about 1 sec interval. This callback (or could we call it a thread?) will check for command from other threads( Pthreads not shown here for update in cmd status). From here onwards, there are two specific command
One to start a looping function
The other to end the looping function
I have done and thought of two ways to create the function and set them to run iteratively.
To create another timeout
using the same method of creating check_cmd
Essentially both to me are pretty much essentially the same method, when I tried both of them. Plan A (as I called it) does not work but Plan B ...actually run at least once. So I would like to know how to fix them...
Or maybe I should use g_source_add_child_source() instead?
In Summary, my question is
when you created a new context and push it to become the default context, do all subsequent function that require main_context will refer to this context?
in a nut shell, how do you add new sources when a loop is already running, ie like my cases
lastly, it is okay to quit the main loop within the callback you have created?
Here is my pseudocode
#include <glib.h>
#include <dirent.h>
#include <errno.h>
#include <pthread.h>
#define PLAN_A 0
typedef struct
{
GMainContext *context;
GMainLoop *loop;
}_App;
static _App l_app;
guint gID;
gboolean
time_cycle(gpointer udata)
{
g_print("I AM THREADING");
return true;
}
gboolean
check_cmd_session(NULL )
{
while(alive) /// alive is a boolean value that is shared with other threads(not shown)
{
if(start)
{
/// PLAN A
//// which context does this add to ??
#if PLAN_A
g_timeout_add_seconds(10, (GSourceFunc)timeout, NULL);
#else
/// or should i use PLAN B
GSource* source = g_timeout_source_new(1000);
gID = g_source_set_callback(source,
(GSourceFunc)time_cycle,
NULL,
NULL);
g_source_attach(source, l_app.context);
#endif
}
else
{
#if PLAN_A
g_source_remove(gID);
#else
}
}
g_main_loop_quit (l_app.loop);
return FALSE;
}
void*
liveService(Info *info)
{
l_app.context = g_main_context_new ();
g_main_context_push_thread_default(l_app.context);
GSource* source = g_timeout_source_new(1000);
g_source_set_callback(source,
(GSourceFunc)check_cmd_session,
NULL,
NULL);
/// make it run
g_source_attach(source, l_app.context);
g_main_loop_run (l_app.loop);
pthread_exit(NULL);
}
int main()
{
pthread_t tid[2];
int thread_counter = 0;
err = pthread_create(&(tid[thread_counter]), NULL, &live, &info);
if (err != 0)
{
printf("\n can't create live thread :[%s]", strerror(err));
}
else
{
printf("--> Thread for Live created successfully\n");
thread_counter++;
}
/**** other threads are build not shown here */
for(int i = 0; i < 2; i++)
{
printf("Joining the %d threads \n", i);
pthread_join(tid[i],NULL);
}
return 0;
}
In Summary, my question is
when you created a new context and push it to become the default context, do all subsequent function that require main_context will
refer to this context?
Functions that are documented as using the thread-default main context will use the GMainContext which has been most recently pushed with g_main_context_push_thread_default().
Functions that are documented as using the global default main context will not. They will use the GMainContext which is created at init time and which is associated with the main thread.
g_timeout_add_seconds() is documented as using the global default main context. So you need to go with plan B if you want the timeout source to be attached to a specific GMainContext.
in a nut shell, how do you add new sources when a loop is already running, ie like my cases
g_source_attach() works when a main context is being iterated.
lastly, it is okay to quit the main loop within the callback you have created?
Yes, g_main_loop_quit() can be called at any point.
From your code, it looks like you’re not creating a new GMainLoop for each GMainContext and are instead assuming that one GMainLoop will somehow work with all GMainContexts in the process. That’s not correct. If you’re going to use GMainLoop, you need to create a new one for each GMainContext you create.
All other things aside, you might find it easier to use GLib’s threading functions rather than using pthread directly. GLib’s threading functions are portable to other platforms and a little bit easier to use. Given that you’re already linking to libglib, using them would cost nothing extra.

C++11 threads to update MFC application windows. SendMessage(), PostMessage() required?

After spending a bit of time with simple UWP applications with C++/CX and ++/WinRT I have begun to enjoy some of the features of targeting that environment for Windows UI app development.
Now having to go back to a more familiar MFC application development I want to change my approach to something that is similar to UWP app development. The idea is to use asynchronous C++11 threads to generate content and modify content that is displayed in the MFC UI.
The main change I want to make is to use C++11 threads to offload some time-consuming tasks and have those threads communicate the results back to the main MFC UI.
Some of the tasks that I am looking to offload onto C++11 threads, which are similar to what I would use with asynchronous tasks with C++/CX and C++/WinRT in UWP apps are:
connect to and exchange data with another computer
open a data file and parse it to update the UI view
convert a data file to another format such as CSV and export to a file
read a file in a format such as CSV and convert the content into a data file
perform searches and filtering of the presentation of the data file in the UI
The problem I am running into is similar to the problem described in Can I have multiple GUI threads in MFC?, however, I am looking for a general approach rather than the specific progress bar update in that question.
I have been trying a simple test with an experimental MFC app using the Visual Studio template which has a tree control docked on the left to build the tree in a worker thread.
If I have a CViewTree, an MFC window that displays a tree view, which I want to update from a C++11 thread, I am currently using ::PostMessage() to request that the tree control in the docked pane is updated.
If I use a lambda with a global std::thread such as the following code:
std::thread t1;
void CClassView::FillClassView()
{
// ::SendMessage() seems to deadlock so ::PostMessage() is required.
t1 = std::thread([this]() { Sleep(5000); ::PostMessage(this->m_hWnd, WM_COMMAND, ID_NEW_FOLDER, 0); });
}
the message handler for the MFC docked pane which looks like:
void CClassView::OnNewFolder()
{
t1.join(); // this join seems to deadlock if ::SendMessage() is used.
AddItemsToPane(m_wndClassView);
}
does indeed update the MFC docked pane with the tree control content just as if the function AddItemsToPane(m_wndClassView); were called at the same place where the C++11 thread is created. The pane update is delayed by 5 seconds when the C++11 thread is used just to provide a visible indication that the thread approach is actually working.
My problem is that I want the C++11 thread to create the content for the tree control and provide it to the docked pane rather than having the docked pane generate the content.
Thus far the only approach I can think of is to develop my own class library that will provide C++11 thread analogues to the MFC library and controls using ::PostMessage() to send the appropriate Windows messages to the designated MFC window or control.
I am wondering if it is possible to have the C++11 threads have their own, shadowing MFC control which they update and then send a message to the UI asking the UI to update its displayed control with the contents of the shadow MFC control? Or is there some other approach that people are using?
I am looking for some other, less arduous approaches to solving this problem of updating an MFC UI from C++11 threads.
By the way #1 ::SendMessage() appears to deadlock on the join() in CClassView::OnNewFolder() which I assume means that some kind of synchronization between the C+11 thread and the UI thread is blocking the C++11 thread from reaching its side of the join()?
Yes there is a deadlock as the thread waits for SendMessage() to return while the message handler is waiting at the join() for the thread to finish. According to the Windows Dev Center SendMessage function:
Sends the specified message to a window or windows. The SendMessage
function calls the window procedure for the specified window and does
not return until the window procedure has processed the message.
To send a message and return immediately, use the SendMessageCallback
or SendNotifyMessage function. To post a message to a thread's message
queue and return immediately, use the PostMessage or PostThreadMessage
function.
By the way #2 It would also seem that using the actual Window handle rather than the this pointer in the lambda for the C++11 thread would be safer. Just in case the this pointer becomes undefined for some reason such as the control is removed?
By the way #3 The Microsoft concurrency namespace, provided via #include <ppltasks.h>, is an alternative to C++11 threads. The concurrency namespace functions are at a higher level of abstraction than C++11 threads and are easier to use.
For instance the above use of std:thread could be rewritten as:
void CClassView::FillClassView()
{
concurrency::create_task([this]() { Sleep(5000); ::SendMessage(this->m_hWnd, WM_COMMAND, ID_NEW_FOLDER, 0); });
}
and this does not require the use of a std::thread join() to cleanly terminate the thread. Also SendMessage() or PostMessage() may be used to send the Windows message since we do not have the same deadlock issue as we have with C++11 threads.
Notes
Note #1: About Messages and Message Queues as well as Using Messages and Message Queues.
For MFC specific content see Messages and Commands in the Framework.
Note #2: Multithreading with C++ and MFC and specifically Multithreading: Programming Tips which says.
If you have a multithreaded application that creates a thread in a way
other than using a CWinThread object, you cannot access other MFC
objects from that thread. In other words, if you want to access any
MFC object from a secondary thread, you must create that thread with
one of the methods described in Multithreading: Creating
User-Interface Threads or Multithreading: Creating Worker Threads.
These methods are the only ones that allow the class library to
initialize the internal variables necessary to handle multithreaded
applications.
Note #3: UWP APIs callable from a classic desktop app which says:
With some notable exceptions, the general rule is that a Universal
Windows Platform (UWP) API can be called from a classic desktop app.
The two main areas of APIs that are an exception to this general rule
are XAML UI APIs, and APIs that require the calling app to have a
package identity. UWP apps have a well-defined app model, and they
have a package identity. Classic desktop apps do not have a
well-defined app model, and they do not have a package identity. A
classic desktop app that has been converted to a UWP app does have a
package identity.
See as well the following blogs from Sep 2012 about WinRT with VS 2012 and Windows 8. Though C++/WinRT with VS 2017 seems more appropriate for Windows 10 than Windows Runtime template Library (WRL) used:
Accessing WinRT From Desktop apps (Part 1)
Accessing WinRT from Desktop Apps (Part 2)
Note #4: MFC Desktop Applications which is a jumping off point with lots of links. See also MFC COM which is a jumping off point with lots of links about MFC with COM along with this article Introduction to COM. See as well MFC Macros and Globals.
As for using AfxGetMainWnd() to get the main application window, the Microsoft developer center has this to say in the article AfxGetMainWnd:
If AfxGetMainWnd is called from the application's primary thread, it
returns the application's main window according to the above rules. If
the function is called from a secondary thread in the application, the
function returns the main window associated with the thread that made
the call.
After some experimentation, there are a few recommendations that I feel comfortable making.
the concurrency task functionality is easier to use than C++11 std:thread and is more flexible in using with coroutines however std::async is easier to use than std::thread and works with co_await as well
coroutines using co_await look to be a great addition with concurrency when using C++/WinRT and the Async type functions in WinRT (see C++ Coroutines: Understanding operator co_await for a technical explanation)
you can make your own async functions using the concurrency::task<> template as the return type of the function or use concurrency::create_task() and you can use co_await with such a task
you can also use co_await with std::async() since std::async() returns a std::future<> which has an Awaitable interface (see await/yield: C++ coroutines though it is dated Nov-2016)
you can also use co_await with a std::future<> as provided by the get_future() method of a std::packaged_task<> ( see also What is the difference between packaged_task and async )
you can make generator functions using std::experimental::generator<type> as a function return type along with the co_yield operator to return a value of the specified type in the generated series
to update the MFC UI requires that any code runs in the MFC UI thread the MFC object was created so Windows messages are needed to communicate with the MFC windows and window class objects from other threads or you must switch the thread context/affinity to the UI thread context for that object
winrt::apartment_context can be used to capture the current thread context and later resumed using co_await which may be used to capture the main UI thread context to be reused later (see Programming with thread affinity in mind in the article Concurrency and asynchronous operations with C++/WinRT)
co_await winrt::resume_background(); can be used to push the current thread's context to a background thread which can be useful for a lengthy task that may be in the main UI thread context and you want to make sure that it is not
when sending messages to a window, make sure that the window actually has been created and exists, during application startup the application must create windows before you can use them; just because the MFC class exists does not mean the underlying window has been created yet
::SendMessage() is synchronous in which the message is sent and a response is returned
::PostMessage() is asynchronous in which the message is sent and a response is not returned
using ::PostMessage() be careful that pointers sent in messages do not go out of scope before the receiver uses them as there is typically a delay between when ::PostMessage() returns and the message handle receiving the message actually does something with the message
probably the most straightforward approach is to use the ON_MESSAGE() macro in the message map with a message handler interface of afx_msg LRESULT OnMessageThing(WPARAM, LPARAM)
you can use Windows message identifiers in the space beginning with the defined constant of WM_APP and the same identifier can be used in different classes
you can use much of C++/WinRT quite easily with MFC with just a bit of care though admittedly I only have tried a few things and there are some limitations such as not using XAML according to the documentation
if you do use C++/WinRT within an MFC application, you are limiting your application to versions of Windows that has the Windows Runtime which pretty much means Windows 10 (this rules out using C++/WinRT with Windows 7, POS Ready 7, etc.)
using C++/WinRT requires adding compiler option /stdc++17 to enable the ISO C++17 Standard for the C++ Language Standard and using coroutines requires the /await compiler option
Here are a view resources.
Microsoft Build 2018
Effective C++/WinRT for UWP and Win32
May 06, 2018 at 3:27PM by Brent Rector, Kenny Kerr
CppCon 2017: Scott Jones & Kenny Kerr
C++/WinRT and the Future of C++ on Windows
Published on Nov 2, 2017
Using Visual Studio 2017 Community edition, I created a new MFC Single Document Interface (SDI) project using the Visual Studio style. After the application comes up, it looks like the following image.
Helper functions for messages
The first change I made was to provide a way to send a Windows message to one of the panes (ClassView or OutputWindow) that I would like to update. Since the CMainFrame class in MainFrm.h had the MFC objects for these windows as in:
protected: // control bar embedded members
CMFCMenuBar m_wndMenuBar;
CMFCToolBar m_wndToolBar;
CMFCStatusBar m_wndStatusBar;
CMFCToolBarImages m_UserImages;
CFileView m_wndFileView;
CClassView m_wndClassView;
COutputWnd m_wndOutput;
CPropertiesWnd m_wndProperties;
I modified the class to provide a way to send a message to these windows. I chose to use SendMessage() rather than PostMessage() to eliminate the pointer going out of scope issue. The concurrency class works fine with SendMessage().
LRESULT SendMessageToFileView(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndFileView.SendMessage(msgId, wParam, lParam); }
LRESULT SendMessageToClassView(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndClassView.SendMessage(msgId, wParam, lParam); }
LRESULT SendMessageToOutputWnd(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndOutput.SendMessage(msgId, wParam, lParam); }
These are the raw, bare infrastructure for sending the messages to update the various MFC windows. I put these into CMainFrame class as that is a central point and the AfxGetMainWnd() function allows me to access the object of that class at any place within the MFC application. Additional classes to wrap these raw functions would be appropriate.
I then put message handlers into each of the classes within the BEGIN_MESSAGE_MAP and the END_MESSAGE_MAP macros. The output window update was the easiest and simplest and look like:
BEGIN_MESSAGE_MAP(COutputWnd, CDockablePane)
ON_WM_CREATE()
ON_WM_SIZE()
// ADD_ON: message handler for the WM_APP message containing an index as
// to which output window to write to along with a pointer to the
// text string to write.
// this->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)_T("some text"));
ON_MESSAGE(WM_APP, OnAddItemsToPane)
END_MESSAGE_MAP()
with the message handler looking like:
// ADD_ON: message handler for the WM_APP message containing an array of the
// struct ItemToInsert above. Uses method AddItemsToPane().
LRESULT COutputWnd::OnAddItemsToPane(WPARAM wParam, LPARAM lParam)
{
switch (wParam) {
case OutputBuild:
m_wndOutputBuild.AddString((TCHAR *)lParam);
break;
case OutputDebug:
m_wndOutputDebug.AddString((TCHAR *)lParam);
break;
case OutputFind:
m_wndOutputFind.AddString((TCHAR *)lParam);
break;
}
return 0;
}
I added the method prototype to the class along with this enumeration to make the functionality a bit easier to use.
enum WindowList { OutputBuild = 1, OutputDebug = 2, OutputFind = 3 };
With the above changes I was able to insert into the message handler for "New" in BOOL CMFCAppWinRTDoc::OnNewDocument() the following code to put a text string into the "Build" Output Window:
CMainFrame *p = dynamic_cast <CMainFrame *> (AfxGetMainWnd());
if (p) {
p->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)_T("this is a test from OnNewDocument()."));
}
Using C++/WinRT with MFC and concurrency
To test this along with testing using C++/WinRT with MFC, I added the following concurrency task to CMainFrame::OnCreate() which is called when the application is starting up. This source spins off a task which then uses the Syndication functionality of C++/WinRT to fetch an RSS feed list and displays the titles in the OutputWindow pane labeled "Build" as seen in the screen shot above.
concurrency::create_task([this]() {
winrt::init_apartment();
Sleep(5000);
winrt::Windows::Foundation::Uri uri(L"http://kennykerr.ca/feed");
winrt::Windows::Web::Syndication::SyndicationClient client;
winrt::Windows::Web::Syndication::SyndicationFeed feed = client.RetrieveFeedAsync(uri).get();
for (winrt::Windows::Web::Syndication::SyndicationItem item : feed.Items())
{
winrt::hstring title = item.Title().Text();
this->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)title.c_str()); // print a string to an output window in the output pane.
}
winrt::uninit_apartment();
});
To use the concurrency and the C++/WinRT functionality I had to add a couple of include files near the top of MainFrm.c source file.
// ADD_ON: include files for using the concurrency namespace.
#include <experimental\resumable>
#include <pplawait.h>
#pragma comment(lib, "windowsapp")
#include "winrt/Windows.Foundation.h"
#include "winrt/Windows.Web.Syndication.h"
In addition, I had to modify the Properties of the solution to specify C++17 and an additional compiler option of /await which are marked with blue arrows in the screen shot below.
Using co_await with MFC and C++/WinRT
From a helpful comment from #IInspectable I took a look at coroutines with Visual Studio 2017 and MFC. I have been curious about them however it seemed that I could not come up with anything that would compile without errors from using co_await.
However starting with a link in the comment from #IInspectable I found a link to this YouTube video, CppCon 2016: Kenny Kerr & James McNellis “Putting Coroutines to Work with the Windows Runtime", which had a source code sample around time 10:28 that finally I was able to come up with something that would compile and work.
I created the following function which I then used to replace the above source with concurrency::create_task() and the lambda with a function call to the following function. The function call was simple, myTaskMain(this); replacing the concurrency::create_task([this]() { lambda in the int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) method and then adding the following source code above the OnCreate() function body.
winrt::Windows::Foundation::IAsyncAction myTaskMain(CMainFrame *p)
{
winrt::Windows::Foundation::Uri uri(L"http://kennykerr.ca/feed");
winrt::Windows::Web::Syndication::SyndicationClient client;
winrt::Windows::Web::Syndication::SyndicationFeed feed = co_await client.RetrieveFeedAsync(uri);
Sleep(5000);
for (winrt::Windows::Web::Syndication::SyndicationItem item : feed.Items())
{
winrt::hstring title = item.Title().Text();
p->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)title.c_str()); // print a string to an output window in the output pane.
}
}
There are two changes that I made from the source of the concurrency::create_task() being replaced:
removed the winrt::init_apartment(); and winrt::uninit_apartment(); since using them triggered an exception and removing them seems to make no difference
moved the Sleep(5000); to after the co_await since leaving it where it was caused the function to sleep for 5 seconds which meant the UI thread slept for 5 seconds
What I found with the debugger was that at the point that the function myTaskMain() was called, there was an immediate return from the function and the UI thread continued running while the coroutine executed in the background. The UI displayed promptly and then some five seconds later the additional actions, updating the Class View tree and the RSS feed list in the "Build" tab of the Output Window happened.
Note #1: One other thing I have run into with other testing is that the UI will freeze for a few seconds (menu is non-functional). This seems to be due to the Sleep(5000); indicating that the code after the co_await is being run on the main UI thread. This change in application behavior started after I began to explore using winrt::apartment_context ui_thread; to capture the main UI thread context in order to then use co_await ui_thread; to return my coroutine thread to the main UI thread context.
What may be happening is that client.RetrieveFeedAsync(uri) is immediately being satisfied with no delay, perhaps from a cache, so rather than pushing the task to another thread and then returning to the caller, the co_await is getting an immediate result back and the function myTaskMain() is able to immediately continue using the current thread which is the main UI thread?
I noticed that in Visual Studio 2017 the co_await used with client.RetrieveFeedAsync(uri) is colored green while the co_await used with co_await ui_thread; is blue. Doing a mouse hover over the green colored co_await I get a tool tip indicating this is a different version of co_await.
Note #2: There is a C++/WinRT function to move to a background thread context, winrt::resume_background() which can be used with co_await. If I modify the above function myTaskMain() by replacing the line of code of Sleep(5000); after the call to client.RetrieveFeedAsync(uri) with the following two lines of code to push the thread context to a background thread, I do not see the freeze (the UI is responsive to menu selections) and the RSS feed text lines are displayed in the "Build" tab of the Output Window after some 15 seconds.
co_await winrt::resume_background(); // switch context to background thread
Sleep(15000);
Rolling an async task using concurrency::task<> that works with co_await
One thing I was curious about was being able to create my own async task that I could used with co_await similar to the async type functions of C++/WinRT. I spent some time searching about until I finally found this article, Concurrency and asynchronous operations with C++/WinRT, with a section called Asychronously return a non-Windows-Runtime type.
Here is a simple demo function that creates a concurrency::task<> with a lambda and returns the task which is then used with co_await. This particular lambda is returning an int so the function is defined as a task that returns an int, concurrency::task<int>
concurrency::task<int> mySleepTaskAsync()
{
return concurrency::create_task([]() {
Sleep(15000);
return 5;
});
}
The above function is then used with the co_await operator in a statement such as:
int jj = co_await mySleepTaskAsync();
which will cause the variable jj to have a value of 5 after a wait of 15 seconds.
The above is used in a function that returns a winrt::Windows::Foundation::IAsyncAction such as the function myTaskMain() above.
If you like you can also just directly use the lambda with the co_await as in:
int jj = co_await concurrency::create_task([]() {
Sleep(15000);
return 5;
});
Or you could have a normal function such as:
int mySleepTaskAsyncInt()
{
Sleep(15000);
return 5;
}
and then use it with a co_await using concurrency::task<> as in:
int jj = co_await concurrency::create_task(mySleepTaskAsyncInt);
Rolling an async task using std::async that works with co_await
While std::thread does not work with co_await, causing a compilation error, you can use std::async with co_await. The reason is the kind of return value that co_await operator requires and the difference in the return value of std::thread, a std::thread, and the return value of std::async, a std::future<>.
The co_await operator requires that the variable it is operating on is a std::future<>, has a get() method to retrieve a result from the thread, and is Awaitable.
#include <future>
int mySleepTaskAsyncInt()
{
Sleep(7000);
return 5;
}
winrt::Windows::Foundation::IAsyncAction myTaskMain(CMainFrame *p)
{
auto t1 = co_await std::async (std::launch::async, mySleepTaskAsyncInt);
// do something with the variable t1
}
Rolling an async task with std::packaged_task<> and std::future<> with co_await
As the co_await requires an Awaitable object, another way to create such an object is to create a task with std::packaged_task<> then start the task and use the get_future() method of the task to obtain a std::future<> which is then usable with co_await.
For instance we can have the following simple function that will create a task package, start the task executing, and then return a std::future<>. We can then use this function as the target for the co_await operator to implement a coroutine.
#include <future>
std::future<int> mySleepTaskStdFutureInt()
{
// create the task to prepare it for running.
std::packaged_task<int()> task([]() {
Sleep(7000);
return 455; // return an int value
});
// start the task running and return the future
return task(), task.get_future();
}
and then in our source code we would use this function similar to:
int jkjk = co_await mySleepTaskStdFutureInt();
The return statement is using the comma operator to introduce a sequence point so that we start the task running and then call the get_future() method on the running task. The result of the get_future() method, a std::future<int> is what is actually returned by the function.
The task that is created with std::packaged_task() must be started with a function like call using the variable. If you do not start the task then the std::future<> returned by the function will never have a variable and the co_await that is waiting for the Awaitable to complete and to provide a value will never fire. The result is that the source after your co_await will not be executed because the co_await will never be triggered.
Generator with co_yield and std::experimental::generator<type>
While investigating co_await I came across co_yield which is used to return a value as part of a generator of a set of values. With Visual Studio 2017 using co_yield requires that the header file experimental/generator be included. Here is a simple example of a generator that generates a series of integers.
#include <experimental/generator>
std::experimental::generator<int> makeSomeInts(int kCount)
{
for (int i = 0; i < kCount; i++) {
co_yield i;
}
}
And this function can be used with a ranged for as in:
for (int kkk : makeSomeInts(10)) {
// code that uses the variable kkk which contains
// an int from the generated range 0 up to be not including 10.
}
The above loop will be executed for each integer value of 0 through and including 9.
More complex message: updating ClassView pan
I also did an experiment with the ClassView tree control to provide a simple way of doing the most elementary actions: create an initial tree control and add to it.
In CClassView class in the file ClassView.h, I added the following data structs. By the way after I was done, I realized this was probably the wrong place to put this since the CFileView class uses the same tree structure so the same approach would work for both of these panes. Anyway, I added the following:
// ADD_ON: enumeration listing the various types of tree control icons which
// correspond to the position of a control in the tree.
// choose either classview_hc.bmp or classview.bmp for the bitmap strip that
// contains the 7 icons we are using for the images in our tree control.
// icons are standard size in height and width (15x15 pixels) in the order of:
// - main root icon
// - tree node icon which can be opened to show nodes beneath it
// - folder icon which is used to indicate a folder
// - method icon indicating a method of a class
// - locked method icon
// - member variable icon
// - locked member variable icon
enum IconList { MainRoot = 0, TreeNode = 1, FolderNode = 2, MethodNode = 3, MethodLockedNode = 4, MemberNode = 5, MemberLockedNode = 6 };
// ADD_ON: struct used to contain the necessary data for a node in the tree control.
struct ItemToInsert {
std::wstring label; // text to be displayed with the node.
int nImage; // zero based offset of the node's icon in the image, one of enum IconList above.
int nSelectedImage; // zero based offset of the node's icon in the image, one of enum IconList above.
};
I created a message handler, and added it to the message map in ClassView.cpp
ON_MESSAGE(WM_APP, OnAddItemsToPane)
and added the actual message handler itself along with a helper function that does the actual processing.
// ADD_ON: function for filling in the ClassView pane using an array of the
// struct ItemToInsert above. array is terminated by an entry with
// all zeros as in { _T(""), 0, 0 }
void CClassView::AddItemsToPane(CViewTree &xwndClassView, void *xrayp)
{
if (xrayp == 0) return;
// the images are icons that are laid out in a line of icons within a single bitmap image.
// see class method OnChangeVisualStyle() for when the bitmap image is loaded and then
// divided up into sections, 0 through 6, of the single bitmap image loaded.
// see classview.bmp and classview_hc.bmp in the ResourceFiles list.
HTREEITEM hRoot = xwndClassView.GetRootItem();
HTREEITEM hClass = 0;
ItemToInsert *xray = (ItemToInsert *)xrayp;
for (int i = 0; xray[i].label.size() != 0; i++) {
switch (xray[i].nImage) {
case MainRoot:
hRoot = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage);
xwndClassView.SetItemState(hRoot, TVIS_BOLD, TVIS_BOLD);
xwndClassView.Expand(hRoot, TVE_EXPAND);
break;
case TreeNode:
hClass = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hRoot);
break;
case FolderNode:
hClass = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hRoot);
break;
case MethodNode:
case MethodLockedNode:
case MemberNode:
case MemberLockedNode:
xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hClass);
break;
default:
break;
}
}
}
// ADD_ON: message handler for the WM_APP message containing an array of the
// struct ItemToInsert above. Uses method AddItemsToPane().
LRESULT CClassView::OnAddItemsToPane(WPARAM wParam, LPARAM lParam)
{
switch (wParam) {
case 1:
AddItemsToPane(m_wndClassView, (void *)lParam);
break;
}
return 0;
}
I then created some sample data for an initial tree and then an add on node.
// ADD_ON: this is the content to be put into the ClassView tree pane.
// this is a tree structure.
CClassView::ItemToInsert xray2[] = {
{ _T("CFakeMainProject"), CClassView::MainRoot, CClassView::MainRoot },
{ _T("CFakeAboutDlg"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAboutDlg()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeApp"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeApp()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("InitInstance()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("OnAppAbout()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppDoc"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppDoc()"), CClassView::MethodLockedNode, CClassView::MethodLockedNode },
{ _T("~CFakeAppDoc()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("OnNewDocument()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppView"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppView()"), CClassView::MethodLockedNode, CClassView::MethodLockedNode },
{ _T("~CFakeAppView()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("GetDocument()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppFrame"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppFrame()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("~CFakeAppFrame()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("m_wndMenuBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("m_wndToolBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("m_wndStatusBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("Globals"), CClassView::FolderNode, CClassView::FolderNode },
{ _T("theFakeApp"), CClassView::MemberNode, CClassView::MemberNode },
{ _T(""), 0, 0 }
};
CClassView::ItemToInsert xray3[] = {
{ _T("CAdditionalDelay"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CAdditionalDelayMethod()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T(""), 0, 0 }
};
I then exercises this message handler by spinning off two concurrency tasks in the CMainFrame::OnCreate() method which did a time delay and then updated the ClassView window tree contents.
concurrency::create_task([this]() { Sleep(5000); this->SendMessageToClassView(WM_APP, 1, (LPARAM)xray2); });
concurrency::create_task([this]() { Sleep(10000); this->SendMessageToClassView(WM_APP, 1, (LPARAM)xray3); });

Access the main OMNET++ simulation thread from a working/child thread

I wrote a simple multi-threaded application in OMNET++ that does not call any OMNET++ API in the working thread and is working as expected. I know that OMNET++ does not support multi-thread applications by design, but I was wondering if there is any mechanism that I can use to make a bridge between my worker thread and my code in the main simulation thread.
More specifically, I am saving some data in a vector in the working thread and I want to signal the code in the simulation thread to consume it (producer/consumer scenario). Is there any way to achieve this?
Do I need to design my own event scheduler?
METHOD 1
The simplest way to achieve your goal is to use a selfmessage in simulation thread and a small modification of worker thread. The worker thread should modify a common variable (visible by both threads). And the selfmessage should periodically check the state of this variable.
The sample code of this idea:
// common variable
bool vectorReady;
// worker thread
if (someCondition) {
vectorReady = true;
}
// simulation thread
void someclass::handleMessage(cMessage * msg) {
if (msg->isSelfMessage()) {
if (vectorReady) {
vectorReady = false;
// reads vector data
}
scheduleAt(simTime() + somePeriod, msg);
}
The place of declaration of common variable depends how you create and start the worker thread.
METHOD 2
The other way is to create own scheduler and adding a condition just before every event. By default OMNeT++ uses cSequentialScheduler scheduler. It has the method takeNextEvent() which is called to obtain next event. You can create a derived class and overwrite this method, for example:
// cThreadScheduler.h
#include <omnetpp.h>
using namespace omnetpp;
class cThreadScheduler : public cSequentialScheduler {
public:
virtual cEvent *takeNextEvent() override;
};
// cThreadScheduler.cc
#include "cThreadScheduler.h"
Register_Class(cThreadScheduler);
cEvent* cThreadScheduler::takeNextEvent() {
if (vectorReady) {
vectorReady = false;
// reads vector data
}
return cSequentialScheduler::takeNextEvent();
}
In omnetpp.ini add a line:
scheduler-class = "cThreadScheduler"

Private variable disappears after thread starts

Problem:
I have a private variable that is available during the startup of a threaded object, but is out of scope when it is used later (via a signal and slot call).
Details:
I have an application that I'm developing in Qt5 for both linux and windows.
Currently it works as expected under linux (where development began), but now
that I'm trying to stand it up on windows 7 (I didn't have a copy of windows initially) I have run into this problem where (on windows only) my private variables go out of scope after the thread initializes.
Question:
What is wrong with my object/thread structure such that the variable scope is fine under Linux, but not in windows? I thought that was the kind of "behind the scenes" stuff Qt took care of? (clearly not)
More Detail:
The order of operation goes like this
Instantiate an object
Move the object into a thread
Get the thread's start signal and call an init function in the object
Later, get data and emit a signal to the threaded object
Threaded object processes data
The code outlining the steps above is summarized below.
void MyWorkerClass::init()
{
// ... bunchOCode
procThread = new QThread; // <-- procThread - private to MyWorkerClass
procObj = new Processor(startupData); // <-- procObj - private to MyWorkerClass
procObj->moveToThread(procThread);
connect(procThread, SIGNAL(started()), procObj, SLOT(doStart()));
connect(this, SIGNAL(dataIsReady(void *)), procObj, SLOT(processMsgs(void *)));
procThread->start();
ok = waitforProcSetup();
// ... Life is good, do more stuff
}
class Processor : public QObject
{
// ... Other
// ... stuff
private slots:
void doStart();
void processMsgs(void * buffer);
private:
QHash<QString, bool> process;
}
void Processor::doStart() // <-- private slot
{
// ... take care of init stuff that couldn't be done in constructor
// Variable is valid here and I can work with it.
foreach(site, locations.uniqueKeys()) {
process[site] = true; // <-- works like a champ
qDebug() << QString("%1 => %2").arg(site).arg(process[site]);
}
}
void Processor::processMsgs(void * buffer) // <-- buffer is malloc'd memory and works fine
{
// ... When MyWorkerClass gets some data it emits a signal that is connected
// to this private slot.
// Simply trying to examine the variable causes a segfault (because it's uninitialized here)
qDebug() << "... processMsgs:" << process.isEmpty(); // <-- wets the bed
}
.
In trying to improve my question, by following the suggestions from the people who commented, I found out what was going on. I was working on creating a small working version of the example I posted (thanks Kuba Ober). The "error" I was encountering was a segmentation fault that could consistently be recreated with the debug line:
qDebug() << "... processMsgs:" << process.isEmpty(); // <-- wets the bed
Specifically, the private QHash variable "process" was useable when I called it the first time (after the thread was up and running)
connect(procThread, SIGNAL(started()), procObj, SLOT(doStart()));
but that same variable acted like it had gone out of scope when I tried to call it the second time
connect(this, SIGNAL(dataIsReady(void *)), procObj, SLOT(processMsgs(void *)));
The signal (dataIsReady(void *)) for this second call is an explicit "emit" that the worker class does when it's collected some data that can be processed. I tried to make that clear in the comments of the example pseudocode, but I didn't take into account that the comment code I included wouldn't stand out that well since it's all grey.
What was really going on was right after I filled "process[site]" with data I also looped over a quint64 array filling it with data too. The loop went 1 element too far and wrote into the "process" variable, making it look to me like it had gone out of scope. In linux it was purely coincidental that it didn't segfault (likely there was padding between the array and the QHash), but the windows runtime exposed the error for the first time.

Does Arduino support threading?

I have a couple of tasks to do with arduino but one of them takes very long time, so I was thinking to use threads to run them simultaneously.
I have an Arduino Mega
[Update]
Finally after four years I can install FreeRTOS in my arduino mega. Here is a link
In short: NO.
But you may give it a shot at:
http://www.kwartzlab.ca/2010/09/arduino-multi-threading-librar/
(Archived version: https://web.archive.org/web/20160505034337/http://www.kwartzlab.ca/2010/09/arduino-multi-threading-librar
Github: https://github.com/jlamothe/mthread
Not yet, but I always use this Library with big projects:
https://github.com/ivanseidel/ArduinoThread
I place the callback within a Timer interrupt, and voilá! You have pseudo-threads running on the Arduino...
Just to make this thread more complete: there are also protothreads which have very small memory footprint (couple bytes if I remember right) and preserve variables local to thread; very handy and time saving (far less finite state machines -> more readable code).
Examples and code:
arduino-class / ProtoThreads wiki
Just to let you know what results you may expect: serial communication # 153K6 baudrate with threads for: status diodes blinking, time keeping, requested functions evaluation, IO handling and logic and all on atmega328.
Not real threading but TimedActions are a good alternative for many uses
http://playground.arduino.cc/Code/TimedAction#Example
Of course, if one task blocks, the others will too, while threading can let one task freeze and the others will continue...
No you can't but you can use Timer interrupt.
Ref : https://www.teachmemicro.com/arduino-timer-interrupt-tutorial/
The previous answer is correct, however, the arduino generally runs pretty quick, so if you properly time your code, it can accomplish tasks more or less simultaneously.
The best practice is to make your own functions and avoid putting too much real code in the default void loop
You can use arduinos
It is designed for Arduino environment. Features:
Only static allocation (no malloc/new)
Support context switching when delaying execution
Implements semaphores
Lightweight, both cpu and memory
I use it when I need to receive new commands from bluetooth/network/serial while executing the old ones and the old ones have delay in them.
One thread is the sever thread that does the following loop:
while (1) {
while ((n = Serial.read()) != -1) {
// do something with n, like filling a buffer
if (command_was_received) {
arduinos_create(command_func, arg);
}
}
arduinos_yield(); // context switch to other threads
}
The other is the command thread that executes the command:
int command_func(void* arg) {
// move some servos
arduinos_delay(1000); // wait for them to move
// move some more servos
}
Arduino does not support multithread programming.
However there have been some workarounds, for example the one in this project (you can install it also from the Arduino IDE).
It seems you have to define the schedule time yourself while in a real multithread environment it is the OS that decides when to execute tasks.
Alternatively you can use protothreads
The straight answer is No No No!. There are some alternatives but you can't expect a perfect multi threading functionality from an arduino mega. You can use arduino due or lenado for multithreading like below-
void loop1(){
}
void loop2(){
}
void loop3(){
}
Normally, I handle those types of cases in backend. You can run the main code in a server while using Arduino to just collect inputs and show outputs. In such cases I would prefer nodemcu which has built in wifi.
Thread NO!
Concurrent YES!
You can run different tasks concurrently with FreeRTOS library.
https://www.arduino.cc/reference/en/libraries/freertos/
void TaskBlink( void *pvParameters );
void TaskAnalogRead( void *pvParameters );
// Now set up two tasks to run independently.
xTaskCreate(
TaskBlink
, (const portCHAR *)"Blink" // A name just for humans
, 128 // Stack size
, NULL
, 2 // priority
, NULL );
xTaskCreate(
TaskAnalogRead
, (const portCHAR *) "AnalogRead"
, 128 // This stack size can be checked & adjusted by reading Highwater
, NULL
, 1 // priority
, NULL );
void TaskBlink(void *pvParameters) // This is a task.
{
(void) pvParameters;
// initialize digital pin 13 as an output.
pinMode(13, OUTPUT);
for (;;) // A Task shall never return or exit.
{
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
vTaskDelay( 1000 / portTICK_PERIOD_MS ); // wait for one second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
vTaskDelay( 1000 / portTICK_PERIOD_MS ); // wait for one second
}
}
void TaskAnalogRead(void *pvParameters) // This is a task.
{
(void) pvParameters;
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
for (;;)
{
// read the input on analog pin 0:
int sensorValue = analogRead(A0);
// print out the value you read:
Serial.println(sensorValue);
vTaskDelay(1); // one tick delay (15ms) in between reads for stability
}
}
Just take care!
When different tasks tried to reach variables at the same time, like i2c communication line or sd card module. Use Semaphores and mutexes
https://www.geeksforgeeks.org/mutex-vs-semaphore/.
Arduino does not supports threading. However, you can do the next best thing and structure your code around state machines running in interleaving.
While there are lots of ways to implement your tasks as state machines, I recommend this library (https://github.com/Elidio/StateMachine). This library abstracts most of the process.
You can create a state machine as a class like this:
#include "StateMachine.h"
class STATEMACHINE(Blink) {
private:
int port;
int waitTime;
CREATE_STATE(low);
CREATE_STATE(high);
void low() {
digitalWrite(port, LOW);
*this << &STATE(high)<< waitTime;
}
void high() {
digitalWrite(port, HIGH);
*this << &STATE(low)<< waitTime;
}
public:
Blink(int port = 0, int waitTime = 0) :
port(port),
waitTime(waitTime),
INIT_STATE(low),
INIT_STATE(high)
{
pinMode(port, OUTPUT);
*this << &STATE(low);
}
};
The macro STATEMACHINE() abstracts the class inheritances, the macro CREATE_STATE() abstracts the state wrapper creation, the macro INIT_STATE() abstracts method wrapping and the macro STATE() abstracts state wrapper reference within the state machine class.
State transition is abstracted by << operator between the state machine class and the state, and if you want a delayed state transition, all you have to do is to use that operator with an integer, where the integer is the delay in millisseconds.
To use the state machine, first you have to instantiate it. Declaring an reference to the class in global space while instantiating it with new on setup function might do the trick
Blink *led1, *led2, *led3;
void setup() {
led1 = new Blink(12, 300);
led2 = new Blink(11, 500);
led3 = new Blink(10, 700);
}
Then you run the states on loop.
void loop() {
(*led2)();
(*led1)();
(*led3)();
}

Resources