The book defines the concept of a "true" FRP system, and one of the properties that comes from this definition is that it deals with concurrency automatically. The Sodium FRP system is the main example given of this, but any FRP system meeting this definition would have to also have this property.
There is a clear delineation between code that is FRP and code that is not FRP. Once a value is passed into the abstract world of FRP, concurrency issues completely disappear. This fact depends on certain rules being followed: Values must be immutable and closures must be referentially transparent. These rules are considered an absolute requirement in a true FRP system, and in return you get an absolute guarantee of no concurrency problems ever.
In a "non-true" FRP systems such as Reactive Extensions (Rx), these rules are not clearly defined, and so the situation is not nearly as nice.
The whole system is transactional, so that all state changes that result from a given input are atomic. When a value comes out of FRP logic as an output, it is then up to the programmer to deal with concurrency issues again. Sodium gives no guarantee of what thread a given callback will be on in this situation, so the code usually needs to delegate to another thread for processing.
The Sodium system does not currently implement true parallelism - and no FRP system does yet (to my knowledge), but this could be done without affecting the external interface of the library. The book talks briefly about some ways this might be achieved. There is one way in particular that would be very easy, and that is using a method called Software Transactional Memory (STM).
In Functional Programming, mutable state is considered evil and is avoided.
In Functional Reactive Programming, mutable state is considered evil but is not avoided. Instead, it's put inside a little box called a Cell/Behavior/Property.
The singleton pattern doesn't really have a direct equivalent in FRP, because the singleton pattern would include an assumption that anyone can modify or read the global state of the instance. FRP would assume that the modifying and the reading of state are at least separate in some way. Can you make the question more concrete?
I can try to explain a little more, if I understand well; we've to code with integrity transparency, so the problem with the specific problem "singleton" , is how can I simulate the "lock" mechanism,to ensure that only 1 instance is always available, in java there is the synchronized but this no too good for performance,then is the static initializer but this is eager initialization, so the alternative is to lock the block to retrieve the instance required, or this problem has nothing related to FRP, thanks very much for your patience