Thomas Karcher wrote:
Hi Dean,
If someone from the ithreads development team is listening: I guess this
is an issue worth considering to have a solution for ... e. g. a
thread-safe array (similar to Thread::Queue) or a more fine-granular
locking mechanism for shared arrays ... not that I really
Hi Dean,
> > Thanks for the enlightening answer. Do you think it is possible to
> > "trick" threads::shared's lock with a reference to the array, i. e. the
> > reference is shared but the array itself isn't?
> Not certain how you intend to do that ? Are you intending to write your
> own XS impleme
Thomas Karcher wrote:
Hi Dean,
Thanks for the enlightening answer. Do you think it is possible to
"trick" threads::shared's lock with a reference to the array, i. e. the
reference is shared but the array itself isn't?
Not certain how you intend to do that ? Are you intending to write your
ow
Hi Dean,
> > I'm writing a multithreaded merge sort that suffers from massive amounts
> > of context switches (as seen by vmstat). The outline of the program is
> > roughly as follows:
> >
> >
> > my @sortdata : shared; // the values to be sorted
> > [...]
> > // starting two threads
>
Thomas Karcher wrote:
Hi there,
I'm writing a multithreaded merge sort that suffers from massive amounts
of context switches (as seen by vmstat). The outline of the program is
roughly as follows:
my @sortdata : shared; // the values to be sorted
[...]
// starting two threads
new threads(
Hi there,
I'm writing a multithreaded merge sort that suffers from massive amounts
of context switches (as seen by vmstat). The outline of the program is
roughly as follows:
my @sortdata : shared; // the values to be sorted
[...]
// starting two threads
new threads( \&mergesort_string, $beg