Custom Schedulers: Customize current time and timed waits

[Quinn Klassen]

Yep I am aware of that. Each "workflows" thread's execute in a serialized
fashion. Workflows themselves are like processes and are not allowed
to communicate with each other except over specific determentics channels.
I do the same in my custom scheduler.

On Tue, Jun 24, 2025 at 10:10 AM Robert Engels <robaho at me.com> wrote:

> Concurrent programming in inherently non deterministic. The only way to
> provide determinism is via locking and other concurrent synchronization
> methods. If you are trying to execute workflows concurrently that have
> shared state/resources - they themselves must use locking semantics to
> communicate.
>
> Without these, this typically degenerates to single threaded serialized
> execution due to required correctness guarantees.
>
> These are the laws of concurrent composition - not mine :)
>
> On Jun 24, 2025, at 11:57 AM, Quinn Klassen <quinn.klassen at temporal.io>
> wrote:
>
> 
> Sure, to be clear I am not doing deterministic testing. I maintain a
> durable execution framework in Java (
> https://github.com/temporalio/sdk-java). To give a very brief overview,
> users can write "programs" (we call them workflows) using our APIs and
> we'll make them fault tolerant. We do this by recording what the program is
> doing into an event log so the workflow can be resumed if the original host
> crashes. To be able to replay the event log and resume the program we need
> the workflow to be deterministic. Obviously that requirement is problematic
> when multiple threads are involved so we have to disallow users from using
> the standard java library to start threads and use our wrappers instead.
> that we can make determentisic.
>
> In most of the other languages we support like Python, Ruby, Dotnet, Rust,
> Javascript we can control the thread/task scheduling so users can use more
> of the languages native constructs. This makes our Java SDK harder to use
> than some of our other SDKs.
>
> Yeah I understand that the current experimental interface is deliberately
> minimal right now. I just wanted to give my feedback/suggestion as a user
> who has, in my humble opinion, an interesting use case that a lot of other
> languages with a custom scheduler do support.
>
> On Tue, Jun 24, 2025 at 8:58 AM Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>>
>>
>> On 22/06/2025 23:24, Quinn Klassen wrote:
>>
>> :
>>
>> For timed operations ideally I would like the virtual thread to request
>> the scheduler it wants to do a timed operation and the scheduler decides
>> how to accomplish this. That may be too high level an interface to add
>> since it looks like more libraries use `
>> java.util.concurrent.locks.LockSupport`. This is my first time looking
>> at the implementation of some of these low level calls, but maybe it would
>> be more realistic to allow a pluggable time source and interception of
>> these parking utilities.
>>
>> Can you say a bit more about what you are doing? Mike Hearn mentioned
>> deterministic testing but I can't tell from your mails if this is what you
>> are doing.
>>
>> In any case, the experimental interface for the scheduler is deliberately
>> minimal. If a virtual thread waits in timed-Object.wait for example, then
>> controls returns to scheduler. When the virtual thread can continue then
>> its task will be queued to the scheduler to execute. This may be triggered
>> by an Object.notify, timeout + monitor reacquired, interrupted + object
>> reacquired. So triggered by the VM or other parts of the runtime. Also
>> timeout is just one of the cases that causes a thread to continue. It's the
>> same with LockSupport.parkNanos. I don't know if you are expecting the
>> custom scheduler (essentially arbitrary code) to run at these critical
>> times but right now, the scheduler is just used to execute tasks.
>>
>> -Alan
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250624/f9e80fb0/attachment.htm>