There are several features that make Breezy a unique tool for its purpose in data-parallel computing analysis.
This last point is particularly interesting because it allows the client application to reference data objects just as they were defined in the program, not at some lower level which the data may have been transformed into by the compiler. Also, a new implementation of Breezy is not required for each new architecture that the language system is ported to. Because Breezy is implemented in the language, Breezy runs on any architecture supported by the language implementation. There is a caveat to this argument in that there is at least one and possibly two necessary modifications that needs to take place in the runtime system for Breezy to work. The one necessary change is in the implementation of the synchronization barrier. Breezy allows the client to access the program information during these barriers only, to ensure a consistent state in the program. The runtime system must modify the implementation of this barrier function to accommodate Breezy by having a single thread of execution call the Breakpoint Executive module before entering the barrier. All other threads enter the barrier and wait for the last one before continuing on. While they are there, they serve requests from the one thread that is in the Breakpoint Executive module. Thus, another requirement of the runtime system would be active messages (the ability to interrupt other threads to answer requests). This may or may not be implemented in the runtime system. In the case that it is not, it would need to be simulated during these barriers.