Created attachment 86993 [details]
The actual test code

Can be compiled with:

gcc -g -Wall -O3 -o gmt gmt.c $(pkg-config --cflags --libs gthread-2.0)

thanks, test case added. however, i had to rework the usleep() statements which together accumulated to really long test runs, which is a no-no for unit tests:
  http://blogs.gnome.org/timj/2006/10/23/23102006-beast-and-unit-testing/

and also, sleeps don't properly force rescheduling across all uni-processor AND multi-core scenarios. that's because depending on UP/SMP, thread load and thread interaction, you might need to sleep or sched_yield(), often it's hard to tell which. so i've resorted to seldom randomized sleep vs. sched_yield now, which shoud amortize to good concurrent execution on any UP/SMP scenario and shouldn't idle for 99+% of the execution time:

      /* shuffle thread execution order every once in a while */                                                                                              
      if (rand() % 97 == 0)                                                                                                                                   
        {                                                                                                                                                     
          if (rand() % 2)                                                                                                                                     
            g_thread_yield();   /* concurrent shuffling for single core */                                                                                    
          else                                                                                                                                                
            g_usleep (1000);    /* concurrent shuffling for multi core */                                                                                     
        }                                                                                                                                                    

Your changes look fine to me. The execution order may become a bit "less random", but probably still good enough to preserve the spirit of the test. The only other idea I had after seeing your changes was be to precompute the desired execution order and force the necessary context switches, but then again, that would make the aspect of the test that it stresses concurrent access to g_slice disappear.