Why is thread safety important?

Discussion in 'Plugin Development' started by kameronn, Jan 14, 2017.

Thread Status:
Not open for further replies.
  1. Offline

    kameronn

    I understand that it would create problems if an async thread tried to place a block but at the same time the main thread tried to place or get that block at the same time, but what would happen?

    I know things like player.sendMessage(); can be used in async events because they cant be modified by another thread by why isnt player.damage();
     
  2. Offline

    Tecno_Wizard

    @kameronn, explaining this technically is a massive nightmare, so I'll give you an anecdote of one of the worst cases of thread-safety failure in history, also known as the North-Eastern Blackout.


    To understand this, you must understand what a race condition is. Imagine you have a boolean you don't expect to change while a process is running. Think of it as a parameter. Now, imagine you're half-way through a lot of logic, and suddenly, it changes. Imagine the chaos it would cause in your code. This is called a race condition, when a thread modifies a value while it is being used somewhere else. There are tons of places in a Bukkit tick where if something suddenly changes, all hell could break loose.

    Now, imagine you don't use thread safety and you cause a race condition. Now, imagine that this program runs the North American power grid. Fun! 85% of the power grid overloaded and it took days to fix the effects.

    https://en.wikipedia.org/wiki/Northeast_blackout_of_2003

    Thread Safety!
     
    ipodtouch0218 and kameronn like this.
  3. Offline

    mythbusterma

    @Tecno_Wizard

    That's not what a race condition is. A race condition is where the value of something is used in two or more threads, and the resultant value is dependent upon the order of execution. What you're talking about is a result of a race condition, although the difference is subtle.

    @kameronn

    Nothing says that Player#sendMessage() is a thread safe method, although considering the message sending is on another thread anyway, it's probably fine. It has nothing to do with whether or not an EventHandler can be "modified," whatever that's supposed to mean.

    Don't use anything in the Bukkit API asynchronously, unless it specifically says you can. Also be sure not to concurrently modify any of your information that you haven't adequately protected.
     
    kameronn likes this.
  4. Offline

    kameronn

    @mythbusterma
    where does it say it can or cannot be modified asynchronusly

    @Tecno_Wizard
    And as for the effect I'm getting it would crash the program with data loss?
     
    Last edited: Jan 14, 2017
  5. Offline

    mythbusterma

    @kameronn

    The result completely depends on what you're doing. In most cases, a crash is the best outcome. However, more often than not, the result is subtle corruption of data in ways that you can't predict or plan for. The outcome could be pretty much anything, depending on what you're doing. Everything from corrupting the world file to the point it can't be read, to randomly dropping players, to accidentally flying players, down to making damage some ridiculous value. It all can happen.

    The list is on the BukkitScheduler JavaDoc page, I believe. Again, this is not "modification," it's just what methods you can and cannot use. Modification of variables is on your end.
     
    kameronn likes this.
  6. kameronn likes this.
  7. Offline

    mythbusterma

    @AlvinB

    That's unfourtunate.

    Pretty much anything in the scheduler class is safe, and nothing else is, @kameronn
     
  8. @kameronn @mythbusterma
    Oh, I forgot to mention, the bukkit wiki states that,

    "The Bukkit API, with the exception of the scheduler package, is not thread safe nor guaranteed to be thread safe."

    So nothing except the scheduler (you'll notice pretty much everything is synchronized in the Bukkit scheduler) is guaranteed to be thread safe (some methods might well be, but the developers issue no guarantee that they are).
     
Thread Status:
Not open for further replies.

Share This Page