Big questions for Swing Developers - Why Swing is not Thread Safe? What makes Sun to design the Swing in a way that it can not handle its operation in multi-threaded environment? What if they made some extra efforts to make it thread safe, many developers would be relaxing now with comparatively simpler code? And so on..
So here is the answer. Swing is not made thread safe intentionally. It was a design decision by Swing team. Why? Because thread safety always comes at a cost. And access of Swing components in multiple threads may not be required that much.
What is thread safety and Why is that costly - Thread safety means that every part of the program should be safe to access from more than one thread concurrently. Program should be able to handle the concurrent access, either by serializing the access or ensuring that it is not disrupting the shared states or operations. Serializing the access means that access should be synchronized for access by thread, which will ensure that only one thread access the code block at a time after taking the necessary lock and hence guarantee the safe access to shared states. Or design has to be done in a way that program block does not affect any shared state or won't disrupt any operations due to concurrent access to states. Both of these changes are costly in term of performance or/and application design/development.
Why Multiple Thread Access may not be required - Because most of the UI operations are done in event fired by UI itself which are sequential in nature. There are few cases when we want to touch UI functions or states in parallel threads, like if we want to perform some time intensive operation to load the data and want to keep the UI active. But these cases are limited.
So if requirement to work in multi-threaded environment is very limited, and cost to make the code ready for multi-threaded environment is high; rationale is not to implement it. However, there should be provision using which developers can manage the UI operations in multiple threads environment also as mentioned above in case of loading heavy data in parallel.
This is what Swing Team analyzed and decided. Result is a high performing GUI development library for most of the scenarios with a capability to work with multiple threads also if required.
So here is the answer. Swing is not made thread safe intentionally. It was a design decision by Swing team. Why? Because thread safety always comes at a cost. And access of Swing components in multiple threads may not be required that much.
What is thread safety and Why is that costly - Thread safety means that every part of the program should be safe to access from more than one thread concurrently. Program should be able to handle the concurrent access, either by serializing the access or ensuring that it is not disrupting the shared states or operations. Serializing the access means that access should be synchronized for access by thread, which will ensure that only one thread access the code block at a time after taking the necessary lock and hence guarantee the safe access to shared states. Or design has to be done in a way that program block does not affect any shared state or won't disrupt any operations due to concurrent access to states. Both of these changes are costly in term of performance or/and application design/development.
Why Multiple Thread Access may not be required - Because most of the UI operations are done in event fired by UI itself which are sequential in nature. There are few cases when we want to touch UI functions or states in parallel threads, like if we want to perform some time intensive operation to load the data and want to keep the UI active. But these cases are limited.
So if requirement to work in multi-threaded environment is very limited, and cost to make the code ready for multi-threaded environment is high; rationale is not to implement it. However, there should be provision using which developers can manage the UI operations in multiple threads environment also as mentioned above in case of loading heavy data in parallel.
This is what Swing Team analyzed and decided. Result is a high performing GUI development library for most of the scenarios with a capability to work with multiple threads also if required.
0 comments:
Post a Comment