Add this_thread_executors

[hkaiser]

• also add executor_traits<>:;has_pending_closures()
• refactoring interface of scheduling_loop
• exit scheduling loop without delay if called from inner scheduler (fixes performance regression)
• add missing #includes

[dcbdan]

What is the rationale behind has_pending_closures?

[hkaiser]

What is the rationale behind has_pending_closures?

We essentially have 2 types of executors: stateless and stateful executors (I'm not sure if these terms are appropriate, though). Stateless executors run the tasks directly, while stateful executors employ the services of more complex scheduling engines to make sure the tasks are run. The has_pending_closures is most useful for stateful executors allowing to detect whether there are still tasks running, i.e. to detect whether it is safe to destroy the executor instance.

[sithhell]

Are the pending closures really the number of OS threads? wouldn't this rather return false for stateless executors?

[hkaiser]

Good catch, that's a bug (copy&paste problem).

[sithhell]

Is the purpose of this executor to confine all scheduled work on the current OS thread? If yes, wouldn't a simple, single threaded scheduler be enough?

[sithhell]

This looks like a copy and paste error.

[hkaiser]

Right, forgot to update the comments

[hkaiser]

Is the purpose of this executor to confine all scheduled work on the current OS thread? If yes, wouldn't a simple, single threaded scheduler be enough?

Well, this is a single threaded scheduler guaranteeing that all work is executed on the same thread as it is initially executed. I needed this for HPXrx (https://github.com/STEllAR-GROUP/hpxrx), I think I can completely move it over to that project, it does not have to go into the main HPX repo. OTOH, it might be useful in other contexts as well.

[sithhell]

On 07/21/2015 03:33 PM, Hartmut Kaiser wrote:

Is the purpose of this executor to confine all scheduled work on the current OS thread? If yes, wouldn't a simple, single threaded scheduler be enough?

Well, this is a single threaded scheduler guaranteeing that all work is executed on the same thread as it is initially executed. I needed this for HPXrx (https://github.com/STEllAR-GROUP/hpxrx), I think I can completely move it over to that project, it does not have to go into the main HPX repo. OTOH, it might be useful in other contexts as well.

I am not saying it shouldn't go into the main HPX repo, it could indeed
be useful, what I am trying to get at is that it seems overkill for a
scheduler which is only used on a single core to include all the
atomics, lockfree algorithms and locks etc..
If I understand correctly, you never enqueue new work from more than one
thread and never steal any work so this might be a valuable optimization
which could come in the future.
With that being said, do you think we absolutely need multiple
schedulers for this executor?

[hkaiser]

If I understand correctly, you never enqueue new work from more than one thread and never steal any work so this might be a valuable optimization which could come in the future.

Right, it's not done anywhere currently, but should be possible to do.

With that being said, do you think we absolutely need multiple schedulers for this executor?

Do you mean the static_priority and local_queue variants I added? The static_priority one does not do work-stealing but enables priorities, while the local one does not expose priorities. We don't have a static local scheduler at this point, otherwise I would have used it instead.

[hkaiser]

All comments have been addressed. I also added a new static scheduler (no priorities and no work stealing) to reduce the overheads for this use case.