Re: next round: glib thread safety proposal

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen 

> > 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.

It would indeed be annoying for users of a platform, where this magic is
not working, that all programs, programmed on linux or solaris, would not
work (and worse, they would crash unpredictable...) thats for sure. We'll
see. The magic is not that important (also because the necessary
configure.in tests are not that much fun...)

> > - 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?

If you are doing a timed wait on an GCond, and you are signaled that
the condition have come true, the GCond wait is not left, before you
reentered the mutex. but you're not garanteed to be the next thread to
enter the mutex, so by the time you enter, the condition might already be
false (condition here doesn't mean GCond, but the condition itself, i.e.
i==0 ) and thus you have to wait again for the rest of the time. If you
would be using relative times, you couldn't do that properly, except when
you would provide a pointer to a long value and would leave the rest time
behind there. but that would not be accurate, if the above would happen
frequently. So technically it is best to use a GAbsTime, we could even
make them be used as arguments and return values (instead of pointers to
them) to make them easier to use (after all, they are as big as gint64),
and by now all c compilers should support this, or am i wrong?
 
> 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 do not know, if the above condition wait scenario would apply to this
too, so it might or might not apply to glib main loop. You'll know best.

> > - 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. :-(

no, the cache coherence protocol to be found on all such systems is
supposed to prevent this. I asked someone from our institute with detailed
knowlege in this topic and he said, that we could rely on such not happen. 

> > 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.

ok, from now on I'll do it. 
Today I only did some minor changes to my code (mainly I made the global
vars use those GUTILS_C_VAR tricks for win32.) So I'll not post something
new now.
 
> > 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.

Could this go into glib before the 1.2 code freeze?

(My hurry is because I could really need this stuff for the multithraeded
ORBit, that I'm currently working on, so at least you should keep calm ;-)

To conclude: Three open issues still:

- what about the thread specific data stuff.

- what about the seperation of mutex and cond function into two classes,
as 
  Aaron suggested. I do personally not think, that this would help, as
there 
  is only one instance of that class anyway, and the user is actually not
  supposed to touch this in normal operation. It's just for some special
  cases (named mozilla ;-).

- what about the GAbsTime, or whatever you name it for your purpose, can 
  they be uses 'by value'. It would make programming much more simple and 
  only very slightly slower.

Bye,
Sebastian
-- 
+--------------============####################============--------------+
| Sebastian Wilhelmi, Institute for Computer Design and Fault Tolerance, |
| University of Karlsruhe;  Building 20.20, Room 263,  D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de;  fax: +49 721 370455;  fon: +49 721 6084353 |
+-----------------> http://goethe.ira.uka.de/~wilhelmi <-----------------+