Re: Informing UI thread of target for sending messages?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

****
Joe: > Not sure why you fastened on this notion that a thread needs to
receive a message. If you
were doing a thread pool, sure, but then the thread would not terminate,
it would only
finish its computation and wait again. But a worker thread using an I/O
Completion Port
(which is a better model for thread pooling) can do this, and it doesn't
have to be a
worker thread
****

vvvvvvvvvvvvvvvvvvvvvvvvvv
Lynn: I guess I've lost track of what you are recommending. Previously I
thought you were strongly suggesting using ui threads with
PostThreadMessage. But now it seems worker threads would be better.

I possibly have incorrect assumptions ... that creating 4 worker threads for
each search would be excessively "expensive". I had in mind that these 4
threads (ui or plain worker) are created once, and are blocked waiting
"work" to do. With ui threads, this unblocking would be with a message. With
non-ui worker threads, this unblocking would be something like an event.

But if worker threads are cheap/fast to create over and over, then that
would greatly simplify things. I guess there isn't all that much more than a
pointer to the function, some stack space, and enough "glue" to swap
registers.

So ..... the search is kicked off by the end-user; 4 threads are created and
they tackle their quarter of the memory buffer to do their part of the
search. They get done, report back, and kaput. The main gui thread organizes
and presents the results.

Something to mention ... the time frame involved is perhaps 1/10 second on a
reasonable modern computer with a dual-core or core-2-duo. Anything over 2
seconds is sluggish. The code is already fast enough for a single file, but
I want it to be "knock your socks off" responsive with parallel search of
20+ files.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

****
Joe: > You are hung up on the concept of UI threads. Drop it.
****

Using messaging, the synchronization is not required. Also, NEVER use
CCrticalSection;
the MFC synchronization primitves are crap and should be avoided. Note
that none of this
synchronization is required

****

vvvvvvvvvvvvvvvvvvvvvvvvvv
Lynn: Ooops ... now I recall reading that in an essay of yours ... my poor
brain is getting overloaded :-(
^^^^^^^^^^^^^^^^^^^^^^^^^

threadsleft = ::InterlockedDecrement(&m_curThreadCountStillWorking);
::InterlockedExchangeAdd(&m_foundCountOverall, foundcount);
m_foundCountPerThread[threadindex] = foundCount;

The first two use hardware-interlock instructions to achieve the
interlock, thus
eliminating the need for any other locking. The last one doesn't need
synchronization
because only one thread can have that thread index, so there is no
concurrent access
involved.

vvvvvvvvvvvvvvvvvvvvvvvvvv
Thanks ... I was wondering about whether the
m_foundCountPerThread[threadIndex] needed to be protected.
^^^^^^^^^^^^^^^^^^^^^^^^^
****
I've said this before: you're taking a simple problem and making it
difficult. Forget UI
threads. They add complexity without adding value.
****


.

Relevant Pages

  • Re: Informing UI thread of target for sending messages?
    ... But now it seems worker threads would be better. ... And UI threads are still not a good choice; an I/O Completion Port ... cost of thread creation would be unnoticeable. ... the MFC synchronization primitves are crap and should be avoided. ...
    (microsoft.public.vc.mfc)
  • IO Completion Ports
    ... i have recently been working with C# async IO. ... back to C++ to write some server software. ... After creating my worker threads and completion port, ... GetQueuedCompletionStatusin my worker threads (i have been using ...
    (microsoft.public.vc.language)
  • Re: ThreadPool Questions
    ... You sould have an output data pool. ... Worker threads all continuously take data out of the queue, ... is good but you want less synchronization between threads. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: adapter.fill and progress bar
    ... worker threads) are synchronized with the control backgroundworker is placed ... Thus you don't need any special synchronization. ... The same could be said for windows - why does windows use ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Sequential consitency on X86_64 - implementation of a bust wait algo not working inspite of
    ... here is a very simple distributed spin-wait barrier synchronization algorithm I have whipped up: ... void wait ... waits for all worker threads to hit the barrier ...
    (comp.arch)