Re: New objects for GLib

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:

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

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,

Sebastian Wilhelmi                   |            här ovanför alla molnen           |     är himmlen så förunderligt blå   |

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