Re: Multithreading question

Svata Dedic

Dne 04. 10. 19 v 8:22 danielb987 napsal(a):
                ThreadingUtil.runOnGUI(() -> {
If it is absolutely necessary for the executed code to (potentially) block the GUI thread... (sorry don't know the intended use, perhaps UI feedback is provided)

public class ExecuteLock {
    private boolean lock = false;
    private boolean again = false;
1/ In a situation, when object.execute() recursively execute()s AND an external thread ALSO execute()s (tries to) before current execution completes, object.execute() will be run just once more. Is that according to your requirements ?

2/ Rigidly, the object job's execution is determined at the monitor exit in loop(). If by a chance a contending thread attempts to execute() in between monitor exit in loop() and actual object.execute() start within GUI thread, an additional object.execute() will run. OK ?

3/ If the thread, that (initializes ConditionNG ?) assigns `object' could be different from *first* thread that enters execute(), either declare `object' final, or have at least one ExecuteLock's monitor exit on the thread that assigns `object' before any execution can reach execute().


Nitpick: if the guard will be exposed as API, consider renaming get() to something like once(), single(). In the API case, I'd consider to implement j.u.concurrent.Executor, if possible.

Join to automatically receive all group messages.