Re: [Gimp-developer] GIMP and multiple processors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 13 Feb 2005 22:10:21 +0100, Sven Neumann <sven@xxxxxxxx> wrote:

> Also tried to port the code to GThreadPool but it turned out to be not
> as trivial as I expected. The current code blocks until all threads
> are returned and it is not trivial to implement this behaviour with
> GThreadPool. So this part, the more interesting part of the TODO, is
> still open.
> 
> I don't want to put more time into this, but I think it would
> definitely make sense to introduce a thread pool to cut down the
> number of thread creations. Any volunteers?

Here's a solution that would work:  (note, untested code, error
checking and unintersting stuff omitted for clarity, etc)

Calling code:
struct SynchStuff {
    GThreadPool *pool;
    GCond *cond;
    GMutex *mutex;
} synch;

typedef struct SynchStuff SynchStuff;

synch.cond = g_cond_new();
synch.mutex = g_mutex_new();


/* create an exclusive threadpool */
synch.pool = g_thread_pool_new(gimp_thread_func, &synch, ...); 

/* make sure that all the tasks are in the queue before checking if
queue is empty.
 */

g_mutex_lock(synch.mutex);

for (/* each task */ ...) {
    g_thread_pool_push(sych.pool, task, ....);
}

/* alll threads are now launched.  allow threads to test queue for emptiness
 * and wait for signal that all tasks are complete */

g_cond_wait (synch.cond, synch.mutex); 

/* all tasks are now complete */

g_mutex_unlock(synch.mutex);



void gimp_thread_func(GimpTaskData *task, SynchStuff *synch) {

  /* process task */
  .
  .
  .

  /* wait until all tasks have been queued */
  g_mutex_lock(synch->mutex);

  if (g_thread_pool_get_num_threads(synch->pool) == 1)
      g_cond_signal(synch->cond, synch->mutex);

  g_mutex_unlock(mutex);
}

We could also try to talk the glib developers into including
g_thread_pool_join, which would block until the task pool is empty. 
It would be nice if the GThreadPool API were modelled on OpenMP to the
extent possible, which I admit is not really stellar because of the
compiler modifications OpenMP requires.  But perhaps some of what
OpenMP does with compiler modifications we can do with macros.

Rockwalrus

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux