Re: New objects for GLib

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Soeren,

> Instead of locking the entire queue for each lookup, it locks only a
> single item. This should make the queue faster because a producer and
> a consumer can then in most cases access it at the same time without
> blocking.

In my experience you often need to hold the lock even longer than the queue
itself (that's why I added the explicit lock/unlock functions and the
_unlocked function variants): Look at a part of GThreadPool:

void 
g_thread_pool_push (GThreadPool     *pool,
                    gpointer         data)
{
  GRealThreadPool *real = (GRealThreadPool*) pool;
  g_async_queue_lock (real->queue);
  if (g_async_queue_length_unlocked (real->queue) >= 0)
    {
      /* No thread is waiting in the queue */
      g_thread_pool_start_thread (real);
    }
  g_async_queue_push_unlocked (real->queue, data);
  g_async_queue_unlock (real->queue);
}

Here I test the length and add a thread, when there is no thread waiting and I
release the lock after that. That makes things slower, ok, but I can now
garantee all sorts of properties, that would otherwise not be possible. I
know, it's not a very convincing example, but thats what I found to be
practical.

Now for your code. It looks, like it only works for exactly one reader and
exactly one writer. But my Queue also works for multiple readers/writers and
thats also what is needed for a thread pool. A comparing performance test of
the two solutions might be interesting for the one-reader/one-writer case,
though.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |