486442 - Will probably soon want a barrier synchronization primitive

Status: NEW

(Core :: XPCOM, enhancement)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Due to the nature of some new projects being explored, it's probably only a matter of time until we need an nsBarrier.  These usually come up in situations where parallelism is used at a fairly fine grain for performance, rather than responsiveness, as we mostly do now.

Here's a reasonable API:

  nsBarrier(int count);
  ~nsBarrier();
  /** When |count| threads arrive, all are woken up and continue.  Any thread
   * arriving before then is stalled. */
  void Wait();

Barriers can be easily implemented on top of monitors, but this is not the most efficient way.

This is very low priority.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: v1

Comment 2

[Benjamin Smedberg]

Comment on attachment 409456 [details] [diff] [review]
v1

Barrier.h doesn't have any comments at all explaining how you'd use it, which seems like a basic prerequisite for reviewing this patch. I'd like to understand who would normally wait on a barrier... wouldn't it just be one thread waiting? Why do we use notifyall?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Since this patch is only for bug 520942, it's probably better to keep the Barrier private to that code until we need it elsewhere.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

We'll want this for parallel selector matching.  David, what bug should we set this to block?

Comment 5

[David Zbarsky (:dzbarsky)]

I'm going to implement the thread pool in bug 631527.