PE periodic function

[gonsie]

API for a callback for a PE function that gets called every GVT (or so).

Initially introduced in e2309b7 (Jan 2011)

Removed by me in 443bfd2 (Feb 2014).

Should we add some documentation? What is a good use/test case for this?

[JohnPJenkins]

"GVT hooks" in general would be enormously useful, representing a time in which we know all events prior to time foo are committed.

A particularly relevant example would be to aggregate and write periodic output, i.e. that from the lp-io CODES component, or, say, optimistic profiling statistics collected by the ROSS runtime. That way, we wouldn't have to buffer an entire simulation's worth of output. I expect this pattern to be quite important for the upcoming project, regardless how exactly it ends up being used.

Another simple example is doing LP/PE cleanup. For instance, we have optimistic-aware free lists in CODES, and I could use the GVT hook to trigger a cleanup of the free list rather than checking it every event.

A couple of questions:

• what does the "or so" remark mean? Is the callback done immediately after a GVT or on some other schedule?
• can this callback also be applied on a per-LP basis as well (via another entry to tw_lptypes or similar)? This would enable the per-LP cleanup example. Without it, we'd have to iterate by hand over the LPs/lptypes to inform them, effectively shadowing the ROSS API.

[gonsie]

The "or so" remark refers to the old g_tw_periodicity variable:

Number of iterations in scheduler (invoked from tw_run )before calling application callout. Default is to call callout for each iteration.

See tw-sched.c:374 from e2309b7

[JohnPJenkins]

Ah OK. So a scheduler iteration in optimistic mode is defined as up to g_tw_mblock*g_tw_gvt_interval event processes + a GVT? (might have got the var names wrong...)

In any case, it's a good idea to be able to limit the callbacks, esp. if we're running a model that needs to run GVT constantly.