Concurrency Model Designing (Part 1)

After having a discussion about the concurrent system development I thought of sharing my ideas on designing concurrent systems, which might help some else also to implementing the the real systems to handle concurrency effectively and efficiently using Java as the programming language.

Intention

Concurrency Model designing is wide subject area. Because of that I have decided to get narrow down my explanation on concurrent programming concepts such as conditional synchronization, mutual exclusion that are applicable to the given simple scenario (scenario will be explained in detail in next few lines) and model them. Furthermore represent the high level implementation of them using Java, In a way that it will maximize the efficiency in handling concurrency. To replicate the real time scenario of handling concurrent access.

Methods

Finite State Processes (FSP) is used as the technique to design the concurrent system and to test the accuracy of the design, using LTSA tool. There where several concerns during the modeling of concurrency using FSP, such as difficulties in identifying reasons for property violations and deadlocks occurred and its very time consuming to identify those problems and correct them to improve the efficiency and accuracy of the system.

Business Case Scenario

A simple user system that can make use of an automated CD vending machine with basic banking facilities. A customer can perform following tasks.

• log-in to the system. This will be actually the initial request goes to the the server before any transaction takes place. (Scenario 1)

• Buy any item available in the Vending machine. When user buying a CD from the CD vending machine, money will be transferred from user select account to the respective bank account of CD venders (Scenario 2)
• Transfer money between any two accounts linked to the debit card. (Scenario 3)
• Inquire about account balance of any account that is linked with the card. (Scenario 4)

Before considering the concurrency model designing, lets look in to system scenarios with a high level picture as shown is the below diagram. The diagram also indicates some of the places where concurrency applies.

NOTE : I have not used any of standard databases, servers or loggers which does the concurrent handling for high extend. The main intention of this is to provide high level idea of handling the concurrent situations by design and implementation.

Places where concurrency applies in this simple business scenario

• Concurrent Access to shared storage objects
  • Account details, Card details (contains the PIN details as well) are binary files in this sample scenario, and these binary files are loaded in to the memory. So these shared memory objects needs to be accessed concurrently by the number of requests coming from CD vending machines (value added ATM machines) and need avoid the data corruption as well.
  • Product details and operator login details at CD wending machine also has binary files in this scenario.
  • Out of those concurrent situations, A,D,F situations needs similar kind of locking mechanism to handle concurrent situations. Because of that modeling concurrency for those scenarios will be considered as one (Share a data object without any data corruption).
  • In this series I only consider the modeling of Account object access for various accessing possibilities to them. Account accessing is the most complex when it comes to modeling it
• Concurrent Requests to the server
  • Every transaction request coming to the server and It should queue the request of should entitle to the request waiting pools
  • Concurrent situation B has a specific situation that has only occur in the server. In this situation concurrency handling needs to redirect request and handle the user requests coming to the server at the same time.
• Out of those concurrent situations, C and H situations needs same kind of modeling of concurrency. It belongs to handling concurrency in user interface level.
  • When user makes a request for any sort of request, user shouldn't experience the blocking of other interactivity on the user interfaces.
• Logger of the system which is E concurrent situation has buffered synchronization.
• When considering all seven concurrent situations, handling all these concurrent situations can be categorized in to 4 main categories as mentioned in above 4 points.
  
  

  Concurrent Access to shared storage objects

  
  As mentioned above, this is the most important part in the whole system. The main problem is handling shared complex common data object which is Account object concurrently. Each and every shared object (In our modeling will be considering only the Account) should have a mechanism to prevent the corruption of data in multiple accesses to the same account at the same time.
  
  In order to depict the concurrent access objects and develop high level models, we need languages, standard modeling mechanisms like UML that allows modeling of concurrency. Since I have not found a industry standard concurrency modeling have used FSP (Finite State Process), a modeling tool, and LTSA (labeled transition signal analyzer), a graphical analysis tool, developed for modeling  and analyzing concurrency in the above scenario modeling. 
  
  

  Finite State Process (FSP) design

  In the following FSP given below, describes how concurrency is handled in Account objects.
  
  
  

  
  /*
   *
   * Concurrency modeling on shared account objects
   * (entitled with a account lock) 
   *
   */
  
  const False = 0   
  const True  = 1
  range Bool  = False..True
  const NumOfPreviews = 2 // Number of Preview requests will be varying depending requests made (this is a demo num for modeling purpose)
  const NumOfUpdates= 2 // Number of Update requets will be varying depending requests made (this is a demo num for modeling purpose)
  
  
  set Actions = {acquirePreviewLock,releasePreviewLock,acquireUpdateLock,releaseUpdateLock,requestUpdateLock,previewBankBalance,updateBankBalance}
  
  
  PREVIEW = (acquirePreviewLock->previewBankBalance->releasePreviewLock->PREVIEW) 
      +Actions.
  
  DEBIT = (requestUpdateLock->acquireUpdateLock->debit->releaseUpdateLock->DEBIT)
     +Actions.
  
  CREDIT = (requestUpdateLock->acquireUpdateLock->credit->releaseUpdateLock->CREDIT)
     +Actions.
     
  LOCK = LOCK[0][False][0][False],
  LOCK [previews:0..NumOfPreviews][isUpdating:Bool][numOfUpdateReq:0..NumOfUpdates][isPreviewTurn:Bool]
    = (when (!isUpdating && (numOfUpdateReq==0 || isPreviewTurn)) acquirePreviewLock -> LOCK[previews+1][isUpdating][numOfUpdateReq][isPreviewTurn]
      |releasePreviewLock -> LOCK[previews-1][isUpdating][numOfUpdateReq][False]
      |when (!isUpdating && (previews==0)) acquireUpdateLock -> LOCK [previews][True][numOfUpdateReq-1][isPreviewTurn]
      |releaseUpdateLock -> LOCK[previews][False][numOfUpdateReq][True]
      |requestUpdateLock -> LOCK[previews][isUpdating][numOfUpdateReq+1][isPreviewTurn]).
  
  
  
  property SAFTY_PROPERTY_TO_LOCK = (acquirePreviewLock->PREVIEW_PROCESS[1]| acquireUpdateLock->UPDATE_PROCESS),
  PREVIEW_PROCESS[i:1..NumOfPreviews] = (when(iPREVIEW_PROCESS[i+1]
             |when(i>1) releasePreviewLock -> PREVIEW_PROCESS[i-1]
             |when(i==1)releasePreviewLock -> SAFTY_PROPERTY_TO_LOCK),
  
  UPDATE_PROCESS = (releaseUpdateLock->SAFTY_PROPERTY_TO_LOCK).
  
  ||ACCOUNT_LOCK = (LOCK || SAFTY_PROPERTY_TO_LOCK).
  
  ||TESTING_LOCKING_SYSTEM =  (  previewer[1..NumOfPreviews] :PREVIEW
                        || updater[1]:DEBIT ||updater[2]:CREDIT
                        || {previewer[1..NumOfPreviews],updater[1..NumOfUpdates]}::ACCOUNT_LOCK).