[email protected]
[Top] [All Lists]

Re: looking for threading advice

Subject: Re: looking for threading advice
From: "Dragos Manoilescu"
Date: Fri, 3 Mar 2006 14:31:55 -0500
 Hi Paul,

 It sounds to me that you need two things:

 1. Reference counted objects.
 2. Sync objects (mutex etc)

 1 gives you the possibility of not having something deleted while
processed or still used by somebody
 2 gives you the possibility of having only one access at a time to a



----- Original Message ----- From: "Paul Miller" <[email protected]>
To: "QT Interest List" <[email protected]>
Sent: Friday, March 03, 2006 2:20 PM
Subject: looking for threading advice

I've got a threaded processing design I am working on, and ran into an
issue with changing an object while a work queue is processing the
object. I was hoping I could get some suggestions on a clean way to deal
with this.

Consider this design:

Object - contains some data used to describe some result
ObjectObserver - points to an Object, used to query the Object result
JobQueue - a queue of processing jobs which runs in a thread
Job - a job which retrieves a result from an observer

So, various UI components get ObjectObservers (which are reference
counted and shared) on various Objects. When the UI needs to generate
data to display for a given Object, it queries the ObjectObserver for a
"result". To do this, it creates a Job which points to the Observer and
submits it to the Queue. Jobs are also reference counted, and the job
owner holds on to a pointer to it as well. When the job executes in the
queue, it signals the owner of the Job that the result is ready, and the
UI component gets the result from the job and displays it.

This all works well, as the UI updates quickly, but only one job can
execute at a time, but in the background.

The problem comes in when I need to set new data on an Object. This
invalidates the Object, and also invalidates any Observers on the
object. When an Observer is invalidated, it signals the owning UI
element to request a new result. However, there still might be existing
request jobs in the queue, which point to the now invalidated observer.
Worse, there might be a job in the process of running in the background
thread which is using the data from the Object the observer points to,
assuming the previous data is there.

I wonder if there might be a cleaner way of dealing with these
interactions, without copying the entire data model for each job
request. Note that some Objects depend on others, so if an Object in the
chain changes, it might invalidate all Objects further down the chain,
and thus all of the Observers, which would trigger new results for all
of them.

One thing I know I should handle better is flushing invalid jobs from the queue when the object (and therefore the observer, and therefore the job) changes. One idea would be to not reference-count the jobs, but to let the owner of the job own the pointer to it. The JobQueue could attach to the destroyed() signal to find out when it is about to be destroyed, and the owner could just delete it if it is no longer needed. If it's in the queue, the destroyed() signal would let the queue remove it, but I don't know what would happen if the queue tried to process the job while it was being destroyed, or if it was in the process of being processed while being destroyed.

If this isn't clear enough please let me know!

Paul Miller | [email protected] | www.fxtech.com | Got Tivo?

To unsubscribe - send a mail to [email protected] with "unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/

To unsubscribe - send a mail to [email protected] with 
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/

<Prev in Thread] Current Thread [Next in Thread>