- Adding new ReferenceWrapper for structs, value types, to avoid thread
race conditions while reading and writting. In C# reference type
assignments are atomic, so it allows us avoid using locks.
Per review comments provided in #3743 regarding the
training/long-running scheduled events and the leaky
bucket algorithm. See the PR for more information.
Deducts the standard time step limit from the additional minutes.
We start counting minutes immediately, even before the standard limit
has been exceeded.
This change ensures that we're not confusing the user with the message
In order to continue to provide debugging support in the QC cloud, the
scheduled events were moved from inside of a task to the algorithm's
main execution thread. This necesitated a different methodology for
managing timeouts. Instead of raising an exception when attempting to
request additional time when none is remaining, we're now simply allowing
the isolator's limit to be reached by virtue of not incrementing the
additional minutes in the time manager. This uncovered a bug in LEAN
engine where if the isolator terminates an algorithm, then the status
of the algorithm (on the algorithm manager instance) isn't properly
updated to indicate RuntimeError. This is in direct conflict with the
status update that is provided to the api, which is RuntimeError, so
this change remedies that issue as well. One of the regression algorithms
depends on this status value being properly flipped to RuntimeError in
the event that the isolator limit is reached.
See #3319
We restrict each algorithm time loop to a pre-determined amount of time.
Exceeding this limit will cause the algorithm to immediately terminate.
This quickly becomes an issue when considering users running trainable
models that have a long initialization period that exceeds the time loop
maximum.
This change provides a mechanism through which a long-running scheduled
event is permitted to keep running and is permitted to avoid the time loop
permitted by requesting additional time. Requests for additional time are
limited according to a leaky bucket implementation whose parameters are
set via the job's controls structure. The fundamental time unit for the
algorithm is a single minute.
Here's how it works. If a scheduled event takes longer than one full wall
clock second then a request is made to the leaky bucket for one more minute.
If the scheduled event continues to take more time, it will continue to
request additional minutes. Each requested minute will prevent the algorithm's
time loop check from terminating the algorithm. When the bucket is empty and
no more minutes are available to be requested, a TimeoutException is thrown
causing a cascade that ends in the algorithm's termination and status being
flipped to RuntimeError.
Additionally, this applies equally to ALL scheduled events. While some helpers
were added with the naming of Train and TrainNow to the ScheduleManager, these
methods don't do anything special and the infrastructure doesn't otherwise
flag them as different, so this feature becomes part of the core Scheduled
Event feature set.
Further, the live scheduled events were not touched and are still pending
further discussion regarding the value added by enforcing a time restriction
when simulation time and wall clock time are equivalent.
Fixes#3319
Extracting this behavior into it's own class. We'll later extend
the functionality of the implementation to enable a training event
a mechanism for extending the current time loop maximum and/or for
flat out disabling it while the training is runnig and the leaky
bucket has capacity.
Martin Molinero