I see this ultimately as a problem of interprocess communication (IPC). You have one process generating work and then another one consuming the tasks and doing the work.
This falls into a classic producer and consumer layout (tutorial from RabittMQ).
The nice thing about message queues is that they guarantee the contract of "this message is guaranteed to be delivered to one, and only one consumer (if it is consumed at all)." This simplifies the IPC as you don't need to worry about the semaphores and shared memory segments or other channels of communication.
Beyond this, you can start to get fancy. You can have two consumers running - though only one will grab the message indicating the task from the queue. You could have the producer pumping out single "consider this" tasks as fast as it can (up to a certain queue fullness) and the consumers processing them once every 800ms - though the exact implementation depends on the problem.
The message queue has an advantage over databases in that its what its designed to do. You can do similar things via mechanisms in the database, but then you will start worrying about transactions and locks. Some databases have gone on to take additional abilities of message queueing as part of the core set of features as described in this post, but a message queue has a general advantage over databases being able to handle more concurrent messages, blocking until you get a message, avoiding deadlocks and races.
How one designs a solution using a message queue for this specific problem is still a bit up in the air as there are many aspects of the domain that are left undescribed, but in general the message queue should be one of the first tools that comes to mind when one starts thinking about how to send messages between one or more processes.