Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
>> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
>> Seems that we got a problem on alphas then. I can see several solutions
>> to accomodate such CPUs:
> From my point of view, these solutions have the following merits and
> demerits:
>> - use only PMCs t
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Seems that we got a problem on alphas then. I can see several solutions
> to accomodate such CPUs:
>From my point of view, these solutions have the following merits and
demerits:
> - use only PMCs that don't cross cache lines
+) No need for memory
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> That isn't necessary. One rmb() after resetting C ought to be
> enough. It ensures that in all cases the other CPU reads str_val as
> NULL. If the vtable is still pointing to the PerlInt vtable, its a user
Having an only rmb() on the writing CPU hardl
Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
>>
>> Yep, that's right. As our PMC size isn't a power of 2, there is a small
>> chance that C and C are in different cache lines and
> Even if the PMC size were a power of two, it woudn't necessitate C
> and
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> > On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote:
> >> + /*
> >> + * if we morph to a string, first clear str_val
> >> + * so that after changing the vtable a parallel
>
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote:
>> + /*
>> + * if we morph to a string, first clear str_val
>> + * so that after changing the vtable a parallel
>> + * reader doesn't get a gargabe pointer
>> +
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote:
>> + /*
>> + * if we morph to a string, first clear str_val
>> + * so that after changing the vtable a parallel
>> + * reader doesn't get a gargabe pointer
>>
