Re: next round: glib thread safety proposal

[Owen Taylor <otaylor redhat com>]

Jeff Garzik <jgarzik@pobox.com> writes:

> > Thats what thread specific
> > data means. you have a global key, shared by all threads and if you query
> > with that key, every thread gets its own data location. that is kind of a
> > resemblence of static vars, only with the obviuos advantage, that every
> > thread has its own.
> 
> Can you give me a concrete example of where this would be useful?
> If each thread needs its own data location, I g_malloc it.  If each
> thread needs access to a global structure, I wrap it in a mutex.

One place where thread-specific data comes in useful is making
old API's thread safe.

For instance, consider, in gtk, the:

 gtk_widget_push_colormap()
 gtk_widget_pop_colormap()

pair. If multiple threads are making these calls, if
they ever release the global GTK+ lock between
the push and the pop, then the results will be
unpredictable.

But if instead of a global colormap, each thread
keeps track of a thread-specific colormap, then
each thread can use these functions freely with
worrying about what other threads are doing.

Regards,
                                        Owen