[parrot/parrot] bf28fa: Use a new thread safe GC block_mark_locked for blo...

[GitHub]

  Branch: refs/heads/threads
  Home:   https://github.com/parrot/parrot
  Commit: bf28faf3f1ec76bc6414603b754cd1b841c702f9
      https://github.com/parrot/parrot/commit/bf28faf3f1ec76bc6414603b754cd1b841c702f9
  Author: Stefan Seifert <nine at detonation.org>
  Date:   2012-04-01 (Sun, 01 Apr 2012)

  Changed paths:
    M include/parrot/gc_api.h
  M src/gc/api.c
  M src/gc/gc_gms.c
  M src/gc/gc_private.h
  M src/ops/experimental.ops
  M src/pmc/parrotinterpreter.pmc
  M src/pmc/task.pmc
  M src/thread.c

  Log Message:
  -----------
  Use a new thread safe GC block_mark_locked for blocking GC

Parrot_block_GC_mark and Parrot_unblock_GC_mark are not thread safe.
They contain a classical race condition when incrementing or
decrementing the counter.

Though taking the interp_lock helped in most cases against setting the
block_mark while the accessed thread's GC was running, it did not
help against the race condition in (un)block_GC_mark itself. So in very,
very rare cases, the GC could still run from the wrong thread.

Making Parrot_(un)block_GC_mark itself thread safe would be a
performance problem since it's used in many places all over the code
base. Instead this patch adds a second thread save block_mark_locked
which is only used by threading code when accessing a foreign interp's
PMCs. The counter is only tested by gc_gms_mark_and_sweep which is
called comparatively rarely so it the test should not have any
measurable performance cost.


  Commit: c2b90c022aa7068f2f866be61fcdf7956dfe3ab7
      https://github.com/parrot/parrot/commit/c2b90c022aa7068f2f866be61fcdf7956dfe3ab7
  Author: Stefan Seifert <nine at detonation.org>
  Date:   2012-04-01 (Sun, 01 Apr 2012)

  Changed paths:
    M src/gc/gc_gms.c
  M src/pmc.c
  M src/pmc/proxy.pmc

  Log Message:
  -----------
  Move GC locking down from get_new_pmc_header into the GC

With this change all GC lock handling is done at the same layer (the GC
GMS implementation) which is the only way to keep the locking strategy
(and the poor programmer trying to understand it) sane.

While allocating new memory is a very straight forward operation,
freeing memory unfortunatley is much more complicated since it can be
done by a mark & sweep run (which naturally has to take the lock) but
also manually through API calls. Therefore I need to tell
gc_gms_free_pmc_attributes if it has to do the locking by itself or not
using a gc_gms_free_pmc_attributes_locked function and the new "locked"
GC variable.


Compare: https://github.com/parrot/parrot/compare/05965d9...c2b90c0