[petsc-dev] Generality of VecScatter

[Dmitry Karpeev]

On Tue, Nov 29, 2011 at 1:01 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Nov 29, 2011 at 12:53, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
>> I understand that any solution requires serialization: atomic reads by
>> the spinning loop would serialize on that read,
>> while pthread_cond_wait requires mutex serialization.  sigwait serializes
>> since it clears the signal atomically.
>> Ultimately, all three rely on atomicity of some sort, but mutexes
>> apparently have higher overhead for it?
>> At least the stackoverflow page that suggests the sigwait solution
>> reports a 40x improvement over the pthread_cond_wait
>> solution (admittedly, I don't know the details of the sigwait stuff).
>>
>
> I wouldn't consider that stackoverflow post to be authoritative, but there
> is a large body of literature on lock-free synchronization.
>

Could you point me to some of it?


> Unless there is resource contention, spinning is always the lowest latency
> choice. All multi-threaded cores have some sort of pause instruction
> because it's necessary to make that design useful. For this purpose, we
> should just spin.
>
> Note that with sequential consistency,
>

What do you mean by "sequential consistency"? If we did serialize the
threads before waking them up?


> you can also provide information about the next work unit when you
> activate a thread. For example, you can pass a function pointer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111129/ce3f3eab/attachment.html>