plugin moltithreading - how use?

today saw this:

so, what is threading i know(not good) but how create dedicated thread for plugin? and when it need?

please simple example if u can. Thanks.

 

First, having a completely dedicated thread for your plugin is not automatically improving performance, it can in fact reduce the overall performance of the server dramatically if it interacts with bukkit at "bad times", e.g. blocking the main bukkit thread from accessing important data. It could also cause data inconsistencies when the dedicated plugin thread and the bukkit thread read/modify the same object at the same time.

Bukkit provides enough secure methods to have a low footprint plugin that only gets executed at certain intervals. It even provides the option to have your code executed in a seperate thread (but still at a time where bukkit believes it is safe to do).

I don't know if Borderguard uses a real dedicated thread or bukkits threading service. I hope its the latter.

That said, creating a thread that isn't controlled by bukkit isn't hard. You just have to instantiate the class "Thread", override the method "run()" with the code that should be run in your seperate thread, and then call the "start()" method on that thread object.

I forgot to put in an example:

Code:

Bukkit.getServer().getScheduler().scheduleAsyncRepeatingTask(this, new Runnable() {

@Override
public void run() {
cleanPlayerDataCollection();
}

}, 5000, 5000);

This is an example for the "bukkit way" to do multithreading. I request bukkit to schedule a task that executes my method "cleanPlayerDataCollection()" every 5000 server ticks. The task is executed asynchronously, that means it will run in a thread seperate from the main bukkit thread.

Further advantages of this are that in the event that my plugin gets disabled, the scheduled task will also be stopped/cancelled. When using your own homebrewn solution with "Thread", you'd have to stop the thread yourself (or it will happily keep on running).

Just checked Borderguards sourcecode and sadly it does multithreading the "bad" way, running an own thread 4 times per second instead of letting bukkit handle it.

So I'll use this to elaborate why this aproach is imho very bad with this specific example:

1. The whole thing will execute 4 times per second, independent of if the server actually did make any changes to the checked data (in this case the player positions) in that time. If e.g. the server is busy and delays everything for 1 second to catch up, this plugin will happily check the same data 4 times in between although definitely nothing of interest could have happened in that timeframe. The same goes for situations where of 100 players only 5 would move, the rest standing around idle. The plugin would check the location of all 100 players, not just the 5 that moved.

2. The plugin calls player.teleport() from its seperate thread. That may cause problems if it overlaps with the execution of PLAYER_MOVE or PLAYER_TELEPORT (or any other event that modifies a players location), because most parts of bukkit and Minecraft server aren't synchronized and therefore not made for usage by multiple threads simultaneously. For example, a player gets outside the border (which is possible because the plugin only checks every 0.25 seconds). Now there is a PLAYER_MOVE event from outside the border to somewhere else outside the border. And while that event gets handled, the plugin finds out that the player is outside the border and teleports him back into the border (which causes the client to get informed about his new location inside the border). The server finishes handling the PLAYER_MOVE event and sets the players location to the target location of the event, outside the border. The player is now outside the border (according to the server) and inside the border (according to the client).

Besides that, this kind of "lazy" border check can be bypassed easily with a clientside hack, but that's a different story.

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