[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: A new framework for embedding ... without CORBA
From:       Graham TerMarsch <gtermars () home ! com>
Date:       1999-10-01 15:56:10
[Download RAW message or body]

weis wrote:
> When using threads at university I considered debugging a pain.
> Perhaps it is gdb or it is inherently bad, I dont know.
> 
> I only saw few situations where threads are really a big help.
> Doing blocking IO without blocking the GUI and
> especially the BeOS approach are one of the few cases where
> I saw that threads helped more than they caused trouble with
> deadlocks, concurrency etc.

From having done lots of multithreaded programming under OS/2 years ago, the
issues relating to debugging separate threads aren't really anything new. 
Unfortunately, most debuggers don't easily (if at all) support debugging of
separate threads.  As for where they're useful, I found back then that threads
were useful for just about anything that you wanted to do in the background;
network IO, file IO, background rendering, background compression, etc.

Looking at issues relating to deadlocks and concurrency, the only reliable way
that we/d found back then to try to avoid these issues is to use critical
sections to access any sort of shared memory area or shared variables. 
Critical sections were almost always implemented using a mutex semaphore,
locking the data structure, modifying it, and then unlocking it.  Without the
mutex, all hell broke loose.

Currently, I'd _love_ to have threads to be able to work with.  I've got
several half-baked apps here that I've been playing with on my own time that
I'd love to finish off, but they've all been sitting there waiting for either
threads to become available, or for me to sit down and work out state machines
for all of the possible things that the IO would be doing in async (mostly
network IO).  I know that kioslaves handle most of this currently as a
separate sub-process, but would prefer to have threads available for those
things that don't currently have kioslaves written (e.g. nntp).

As for ways to do inter-thread communication, when we'd been working under
OS/2, the easiest way that we'd been using to do this was either through a
shared data structure, or by having the worker thread stuff a message into the
event loop that'd be picked up the next time through telling the UI thread
(main thread) that the background operation was complete.  Multi-thread
communication is always going to be a bitch, unless theres some way that we
can get a worker thread to call off to a Qt signal to tell the main thread
that the worker thread is finished.  I'll be honest and say that i've got no
idea how this could be implemented in Qt/KDE, but if anyone has something
workable fr threads I'd love to use it as it'd make life so much easier for
me.

I'm going to wager that there are some people on this list who haven't dealt
much with multi-threaded applications before, so if people have questions
regarding some of the general issues that arise, do feel free to e-mail me
with questions (if it doesn't hit my Inbox I'll likely not catch it the first
time).  If it's of any use, though, these articles were ones that I'd used in
the past when doing threading under OS/2; they may be of some interest to
others looking for general conceptual information:

http://www.edm2.com/0106/threadspm.html
http://www.edm2.com/0407/semaphores.html

-- 
Graham TerMarsch

// -----------------------------------------------------------------
// Do not sleep in a eucalyptus tree tonight.   
// -----------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]