• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

FRP:Book-How does the book treat the problem with concurrency?

 
Greenhorn
Posts: 27
Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi authors, with the FRP which concurrency problems are solved easily?
 
Author
Posts: 12
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Enrique,

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).


Steve
 
Enrique M. Talavera
Greenhorn
Posts: 27
Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whoa,thanks for the detailed reply!!, perhaps this is a silly question,but how could I replicate the Singleton Pattern with FRP,if the state is evil and should be avoided ?
 
Stephen Blackheath
Author
Posts: 12
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Enrique,

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?


Steve
 
Enrique M. Talavera
Greenhorn
Posts: 27
Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Stephen Blackheath
Author
Posts: 12
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Enrique,

That problem is outside the scope of FRP.


Steve
 
reply
    Bookmark Topic Watch Topic
  • New Topic