Dear Support,

I am trying to find out the best way to update certain chart objects (these are texts) in every second, minute, hour, or whatever refresh rate I want. These objects are (will be?) created by an indicator.

The indicator`s calculate() method (as far as I can see) being called upon new ticks. So this cannot be a place for 1 second operations.

Is there a context.executeTask() equivalent function for IIndicatorContext, as it is there for IContext?
Shall I create a class within the indicator that extends Thread? And let this thread take care of the update?
Or shall I create a strategy, which will take care of the indicator to be called (together with showing those text objects on chart), and next to this it would also handle to update/refresh job of these chart objects with the help of context.executeTask()?


Please advice!

Thanks and regards.

I'd think the IStrategy route would be much more flexible.

That would be my choice for operations which are event driven or timer driven to cause regular chart paint operations via IContext.executeTask during sparse data conditions.

HyperScalper

Consider scheduling an execution (since it does not involve trading it can simply run in a separate thread - there is no necessity for [url]IContext.executeTask[/url], see):
https://www.dukascopy.com/wiki/#Threading/Scheduled_asynchronous_execution
In either case chart objects are easier to be managed from a strategy.

Thanks for the quick responses! Both of you.

I am although a bit confused. As first you mention there is no real need for context.executeTask(), but then the linked example uses it.
So how should I interpret the answer:
Use a simple (java) thread within a strategy?

Thanks for the super-fast reply.

Yes, be very careful on cleanup if the strategy is to be started/stopped in the JForex environment, for example.

But if you're in a standalone client, it's less important because everything will terminate when the client process terminates.

I like to implement some interface "Stoppable" on my Runnable tasks, with some method "stop()" in all of my threaded tasks, so the thread will exit. Just keep a collection of all your "stoppables" and be sure you stop them in the strategy's onStop exit. Stopping means that the thread is designed to exit cleanly. Don't stop threads forcibly; simply set a flag which the thread will detect and return.

Personally, I would always use IContext.executeTask, even though you are only doing an update of the charting and do not require order processing. This just makes it "cleaner" since things execute on the callback thread for the Strategy, which is the normal way it would be done when not using separate threads.

HyperScalper

Thanks for the tips, hyperscalper!
I also decided to use the context.executeTask(), as it looks perfect for me.

The context.ExecuteTask() is there to allow you to interact with the strategy engine in a thread safe manner.

The question of thread safety only occurs in the context of your attempting to concurrently read / write critical state that the strategy engine thread interacts with, where such reading and writing is caused outside the sight and control of the IStrategy interface and thread.

According to the OP's requirements, the data items that will be touched periodically do not come under the scope of the strategy thread, whether such touches occur within an IStrategy method or not. I presume also that the creating indicators do not attempt to modify the objects they have created after the fact.

To understand the fundamental problem with executeTask() I'll illustrate the extreme:

Consider that your timely periodic needs are critical and must execute on time (e.g. not minor GUI updates but real time portfolio exposure/analysis logic or periodic dynamic hedging calculations), then further consider what happens when the complexity of the core strategy (currently or later as it evolves) being executed over the IStrategy methods onBar(), onTick() and onMessage(), etc causes the strategy engine to arrive at its opportunity to process and call scheduled executeTask() jobs long after your critical 1, 2 or 5 second window.

You have no guarantees at the JVM/OS level as you've given the option-to-execute your critical task to the strategy thread which is already contracted to address the main strategy (no matter the scope or complexity of the same strategy). The only reason executeTask() exists is to stop other threads causing illegal state changes that could bring down the IStrategy engine.

Now, seeing as we're talking GUI updates, feel free to proceed as you have indicated but do make note of the point Support is making - it's important.

calculate() in the Indicator interface should be considered a method that is called RANDOMLY. It doesn't necessarily require a new tick for it to be called. This makes managing things like threads or non-contextual updates/instantiations/clean-ups (the context here is indicator calculation) tricky and it makes addressing the notion of time correctly within it the job of a very costly algorithm.

onBar() can be a great place to address the notion of time as it inherently attempts to call you back after a certain amount of time in a thread safe way. These calls aren't guaranteed time-wise and become less reliable (or at least the perception of error in accuracy increases) the lower you go e.g. TEN_SEC (or ONE_SEC if that's supported) due to lots of things CPU throughput, running threads, network latency (the callback is from the server), strategy complexity, free heap/disk swapping, other apps running on the overall system, etc. But it's a good and safe place for approximating timely call backs for 95+% of use cases.

Ultimately, the example Support pointed you to is the essence of how you address periodic thread execution.

Before we would use Timer / TimerTask Java APIs but with java.util.concurrent we have Executors to play with allowing us to ask the JVM (and not the strategy thread) to take care of our periodic execution:

 
.
executor = Executors.newSingleThreadScheduledExecutor();

   Runnable periodicTask = new Runnable() {
      public void run()
      {
         context.executeTask(hlineTask);
      }
   };

executor.scheduleAtFixedRate(periodicTask, 0, execIntervalMillis, TimeUnit.MILLISECONDS);
.

Despite the reference to context.executeTask() the main point of concern are the executor = Executors.newSingleThreadScheduledExecutor(); and executor.scheduleAtFixedRate(periodicTask, 0, execIntervalMillis, TimeUnit.MILLISECONDS); lines.

This is how you ask the JVM to run some work for you at some interval of your own choice with harder guarantees than you'll get if you stick context.executeTask() in there and delegate the completion of the task to IStrategy when it gets the chance.

Of course, the minute you plan to modify critical state such as orders, etc then you have no choice irrespective of your timing regime to rely on executeTask().

CriticalSection, I really appreciate your reply, and the help!

I`ve read it a couple of times, but I am not sure if I understand what you are trying to say. If I may ask, could you reply on return? Just to confirm that I got it .

So, I think what you are trying to explain is that executeTask() on its own is not `safe` enough to run a job in every second, as it is not guaranteed that the main strategy can `get there` in time, due to its (the main strategy`s) complexity.
And because of this, it is important that the executeTask() is called within the context that you have showed in the code snippet, and how it is visible in the example Support provided. Because of this mentioned context, there is harder guarantees from the JVM itself that we could `get there` in time, and the 1 second execution will really take place.

context.executeTask(Callable) is a mechanism used by you (once, every minute, second, etc) to schedule some task for execution by the strategy thread around it's existing work servicing the IStrategy interface by calling your implementation of the methods in that interface. If you keep your strategy methods efficient then in most cases the job you have scheduled with context.executeTask(Callable) will meet the one second window on most CPUs. In extreme cases if your onBar() or onTick() is quite involved e.g. historical lookups (price bars, indicator values), some analysis calculations, perhaps some I/O (file or DB), etc, etc then in theory the strategy thread is tied up until these methods return - only then will it see to the task you have scheduled with context.executeTask(Callable).


actually the opposite - it is the unnecessary use of context.executeTask(Callable) in that snippet (for your purposes - as presented in the initial post) that would introduce the need to consider the paragraph above.


Not quite, let's look at the snippet again:

.
// Obtain a reference to our thread executor
[b]executor = Executors.newSingleThreadScheduledExecutor();[/b]

   // 'periodTask' is our little task we would like to be executed periodically
   Runnable[b] periodicTask[/b] = new Runnable()
   {
      public void run()
      {
         // We arrive here 'on time' when the thread executor calls us....
         // The JVM controlled the call so the execution of this run happens concurrently to the strategy thread in a separate thread
         // and is 'quite' deterministic.
         // At this point we are free to take care of what ever periodic activity we are interested in doing
         //
         // The ONLY REASON to insert context.executeTask(Callable) here is to tackle work that results in a concurrent change
         // of (or in a dangerous read of) critical state belonging to the strategy thread.  Using context.executeTask(Callable)
         // allows the strategy thread to execute the Callable task safely around its own activities - at its convenience
         //
         // So,
         //
         // 1) if we schedule  context.executeTask(Callable) here - in theory - when will it execute?
         // 2) meanwhile run() will return and wait for the next period to come around and re-call run()
      }
   };
 
// Use the thread executor to run our periodTask as needed (in the background, in a separate thread)
// JavaDoc for this call:
//     scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit)
//         Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently
//         with the given period; that is executions will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period,
//         and so on.
[b]executor.scheduleAtFixedRate(periodicTask, 0, execIntervalMillis, TimeUnit.MILLISECONDS);[/b]
.

For your purposes, it's not the biggest deal but once we start introducing our own threads it's important to understand the thread interactions we introduce and what the consequences of these are for performance and reliability going forward.

Hope this helps