Here's what one of the Worklight architects says:
Worklight runs the requests in separate threads, where the global variables are accessible to all those threads as a shared Scriptable object. So technically, two concurrent requests from the same session updating multiple fields of the shared object may leave that object in inconsistent state.
However from the application logic point of view, it's a rare situation where an application sends concurrent requests updating the same data with different values. Usually it is an undesired flow and is prevented by the application on the client side (by using a busy indicator, etc...). If necessary, the developer can use simple sync constructs in the adapter code, like maintaining an "inProgress" boolean global variable, and reject an update request if inProgress == true.
If there is a real use case requiring synchronization, it would be interesting to learn it and maybe propose a different solution.