develooper Front page | perl.ithreads | Postings from December 2012

Undefined thread object for main thread (tid zero) even though themain thread exists

From:
David Mertens
Date:
December 3, 2012 04:53
Subject:
Undefined thread object for main thread (tid zero) even though themain thread exists
Message ID:
CA+4ieYXUfP-dv8mX_TmJkTc5N+pjULcQEqxuOuWrr_2CP52Tcg@mail.gmail.com
Hey folks -

I am working on a module to share PDL data (C-like arrays of data) across
threads. It pretty much works, but it's not quite as rock-solid as I'd
like. I'd first like to solve my immediate problem, then perhaps open the
larger discussion of how one shares (scalar) objects whose guts are
actually C structs. (I am interested in this both for use in Prima as well
as PDL, and likely other modules that I will come across or write. But I'm
getting ahead of myself.)

My current module works by letting users share PDL *data*, rather than
sharing the piddle itself. Since I cannot share the actual piddle (due to
the difficulties with sharing C structs across threads), I simply tick up
the original piddle's refcount and store the data pointer in a shared Perl
hash. Then, when the user requests a shared copy of that data in a thread,
I create a *very* thin piddle wrapper around the C array of the original
piddle. Believe it or not, it actually works! With any luck, I may even be
able to use this for real multicore high-performance computing stuff.

However, life being what it is, there are corner cases. If that original
piddle's thread terminates, the interpreter frees the memory and the data
goes away. Any wrapped piddles in other threads are now ticking
segmentation faults just waiting for a data read/write.

To help prevent that situation, I decided to store the thread id in which a
piddle's data is first shared. At the very least, this would let me check
that the data's originating thread is still around, and croak if this were
not the case. That code looks something like this:

----%<----

defined (threads->object($originating_tid{$name}))
    or croak("retrieve_pdls: '$name' was created in a thread that "
    . "is no longer available");

---->%----

In my test suite, I create and store data in the main thread. For this
example, then, $originating_tid{$name} == 0 for all cases considered. The
problem is that only the main thread is capable of retrieving the threads
object for tid 0. Any other (child) thread gets an undefined value. Does
that surprise anyone? Are child threads able to get the thread objects for
their parents or siblings?

Thanks!
David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About