Re: next round: glib thread safety proposal

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> > This solution is not incompatible with eventually doing
> > clever tricks with weak symbols to avoid the need for
> > another library, but I think it provides a simpler
> > system at a fairly small additional cost. Are there
> > any problems with this approach that I am missing?
> 
> I think, its more error prone on most of the systems, that do have the gcc
> and ELF (i.e. weak symbols), because here some people might miss to
> initialize the threads and such experience 'bugs'. So it seems to become a
> new FAQ (a'la 'I want to connect a signal to my C++ class member function'
> ;-), but I admit, the automatic initialization could be added later
> without much hassle also for the g_thread_init() approach.

I'm always a bit hesitant to encourage sloppiness on one platform
(even if it is the most important one ;-) when the approach
will fall over on another. 
 
> > > So do something like:
> > >
> > > G_MUTEX_STANDARD_IMPLEMENTATION;
> > >
> > > int
> > > main()
> > > {
> > >   /* working thread safe on platforms with and without weak symbols */
> > > }
> > 
> > I don't see how a single macro could do both of these (especially
> > in the absence of weak symbols). The user would have to call some
> > function inside there main(), I would think, which brings us
> > back to g_thread_init().
> 
> Yes, that was my mistake. I though of an initialization of the function
> table, but that would only work, if defined at the same time, which isn't
> possible, as it already is defined  external (in the lib). So that would
> indeed suggest a solution with g_thread_init. and here it is: a new
> proposal: there are three main changes from the old one:
> 
> - it was a bad idea to use the duration as a relative time. we have to use
> an absolute ending time for the wait. this however doesn't fit to well
> into the current setup. I added a type GAbsTime, which basically is struct
> tm, but as this type is not to be found on win32, I added a new type. I
> actually do also think that to use this would be better for the new glib
> mainloop too. we could then have some convienience functions to manipulate
> them, i.e. get the current time, add n microseconds, subtract another
> AbsTime and so on. 

Could you expand a bit more on why relative times are bad for
timed waits?

In my new main loop, I already have GTimeVal (== GAbsTime) and
g_get_current_time(), used for absolute times.

Millisecond intervals are still used for timeout specifications,
and for the timeout on the central poll. (For compatibility, and for
convenience, and because the main loop cannot make guarantees about
time of delivery of its timeouts in any case, and because poll() only
has millisecond specification for the timeout.)
 
> - I added GStaticMutex, that can be used after being initialized
> statically. Much more convenient, than having to do dynamic initialization
> on your own. This however builds on GMutex, and as such is slower (but
> just one non-zero-test after first time use) 

Hmmm, I think the following scenario can occur on SMP machines:

 1) Thread A finds a uninitialized mutex, and calls 
    g_static_mutex_init()

 2) Thread A initializes the mutex (in cache) 

 3) Thread A writes the pointer to the mutex into main memory
 
 4) Thread B finds the pointer, follows it to the (as yet
    unitialized) contents and tries to use them.

 5) Thread A writes the contents of the mutex into main memory.

As I understand it, to guarantee ordering of writes from one
processor, as seen from another processor, you need mutexes
on both sides. :-(

> - we do need the thread specific data function. because the
> allocating_for_mem_chunk counter in gmem.c must be thread specific. I have
> however not done anything about it, because we could work around that
> particular problem and that might be better anyway. (I havn't looked yet,
> if there are other cases, where glib would need thread specific data, but
> it might be handy to have, could be added later though, it might be best
> just to get the current aspect right before that.)
> 
> so attached as usual a patch and a tar (BTW: would it be simpler for you
> or anybody to not post it, but put it on the ftp-server???)

It would be a bit easier for me, though either is workable. It
also has the advantage of having all the patches archived there
for future reference, instead of spread through the mailing
list.
 
> I already did a decent configure.in extension and I moved most of the
> stuff to a new directory gthread/, because the whole thing might be
> extended to support threads someday, and as it is an extra library, I
> thought this would be the right thing. I also did an extra support for
> solaris mutexes as posix mutexes are simulated using solaris mutexes on
> solaris and thus solaris mutexes are faster than the posix ones.

This all is looking pretty good now.

                                        Owen