[petsc-dev] Generality of VecScatter

Jed Brown jedbrown at mcs.anl.gov
Tue Nov 29 13:01:58 CST 2011


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. 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, 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/1eb87d0a/attachment.html>


More information about the petsc-dev mailing list