Solved Async Event Priorities

As everyone who is knowledgable knows, any 2 async/multithreaded task can end up in a race condition. Now to avoid a race condition between 2 plugins I am making, I was wondering if Event Priorities still hold in async events, specifically the AsyncPlayerChatEvent.

I have one plugin that is cancelling chat and another plugin that is doing some fancy stuff scanning on valid player chat. So does all the AsyncPlayerChatEvent Lowest Priority threads get executed in parallel and sync up before the AsyncPlayerChatEvent Low Priority threads get excuted (and so forth)?

 

Not so sure about this. I think if any event can have a EventPriority tag at the top then it is possible.

krisdestruction

 

Well obviously this is how you have to do it, but I'm asking if and how it will work if I do that. I'm looking for a definitive answer rather than "I think it will work". I'll be running some tests soon to see if there are any unexpected conflicts to indicate it's not working.

 

krisdestruction I think if you are able to edit the plugins or have access to them, yes you can. If you made a custom plugin and the other one is not owned by you, just set the EventPriority tag on you're event to highest. Example:

Code:java

 
@EventHandler(priority = EventPriority.HIGHEST)
public void chatEvent(AnsycPlayerChatEvent event){
//so and so
}
 
 

 

Well both are my plugins, so yes I'm able to edit them. This is how I'm already doing it except one's at lowest for canceling invalid chat, another one's at normal to add fancy stuff as suggested by the Event Tutorial on the Bukkit Wiki. However I just wanted to see if anyone knew the technical details regarding Bukkit's implementation and if they can confirm this works.

Well according to this, it should apply to this as well. Can you confirm _LB?
https://forums.bukkit.org/threads/g...ht-the-plugin-version.788/page-3#post-2727813

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

krisdestruction There is only one thread for chat and all asynchronous AsyncPlayerChatEvents are fired from it.

 

They are executed in order.

Here, take a visual. AsyncPlayerChatEvent is called from two threads, A, and B.

Code:

| A      |-> | Lowest | -> | Low     |
| B      | -----> | Lowest | -> | Low     |

In either case, both are executed in order, but operations from both are also allowed to be interleaved, therefore, you must synchronize or the other thread may interfere.

 

xTrollxDudex There is one thread for chat, but AsyncPlayerChatEvent can be called from the main thread by plugins - you can check #isAsync()

 

xTrollxDudex _LB

_LB is right Troll Dude, each specific event is handled on exactly one thread. Unless your code ( krisdestruction) interacts with other threads inside of the event handler, you cannot create a race condition, as you are only dealing with one thread (not necessarily the main thread, however).

 

mythbusterma The only semi-guarantee is that a single event instance gets processed on one whole thread at a time - other than that, you just have to hope that other plugin developers have brains in their head. What I mean by semi-guarantee is that you can go through all the event listeners and pick and choose which ones to call from which threads, but of course any developer which does such a thing should be shunned

 

_LB

True, but he's only worried about his two plugins he said. Besides, I don't think you could get a race condition unless you're vying for the same resources, which I'm not even sure how you would do unless your plugins are interacting.

 

callEvent does not execute events on a single thread, depending on where it is being called

 

As far as I know, callEvent() calls all event listeners for all priorities on the same thread that it was called from. You will not suddenly see it shift into another thread in the middle of calling the event handlers.

 

I never said it would, what if the thread calling the event was not from the main thread?

 

mythbusterma _LB xTrollxDudex
I see, thanks for the details on the implementation going with _LB's answer. So I guess I should ask what happens if there are two hooks onto an event with the same priority. I would assume that the order isn't visible to the dev.

I'm surprised the chat thread doesn't do something like this for performance. Of course, there's always a question of overhead of creating threads.

Code:

ChatThread ----> LowestA ----> ChatThread ----> LowA ----> ChatThread
           ----> LowestB ---->            ----> LowB

 

Correct - the order is implementation defined.

It could not because then the setFormat and setMessage methods would need to be synchronized, as well as adding/removing targets from the set of targets. There's no reason to bother with squeezing out more performance as it is already performant enough.

 

Ah I see, thanks for clarifying that.