Nothing will interrupt anything and you won't have problems with synchronizing all the threads. Just start thinking in asynchronous manner.
Nothing will interrupt anything and you won't have problems with synchronizing all the threads. Just start thinking in asynchronous manner.
@wysota:
this is interesting as i'm also looking into implementing threaded architecture. from what you are suggesting single thread with asynchronous handling will do the job. but isn't it much more efficient if multiple threads are involved? let's take for an example a method(slot) handling the signal in a single thread, wouldn't that stop or delay other processing as compared to concurrent processing in multithreads?
i'm still quite undecided whether to implement asynchronous handling in one thread or implement multiple threads. would really appreciate your expert advice as to which one is more efficient. thanks.
It seems that your threads will be mostly I/O bound - ie, they will spend most of there time waiting for an i/o event to complete, so really, it makes no sense to use them for these functions (you can of course, but it'll just use up more resources and make coding more difficult).
If you were doing something like a long computation then threads would indeed make sense, but your serial routines definitely do not need threads, and your database thread is questionable too (ie, you would have to be doing some heavy processing over millions of rows and not just simple inserts or selects)
jimc1200 (1st July 2010)
Thanks fatjuicymole for your insights. I think a single thread with asynchronous handling will satisfy my requirements for now.I'll try to check if there's any considerable slow down in the IO operations and if such is the case I might start adding threads. But that would be my last resort as threading adds significant complications in the code ,more so when debugging![]()
Bookmarks