Dropbox and Erlang

Published: 2021-07-07 00:03:04
essay essay

Category: Software Engineering

Type of paper: Essay

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Hey! We can write a custom essay for you.

All possible types of assignments. Written by academics

Abstract – This Document is about the concurrency issue arise when users try to access the same file for different operations, i.e., reading and writing the same file. The solution to this concurrency will be implemented using Erlang by using mutual exclusion technique. We will try to resolve or minimize the concurrency issue through the use of a semaphore. Keywords – Erlang, semaphore, mutual exclusion (Mutex), concurrencyINTRODUCTIONIn this document, we will be trying to solve the concurrency issue generated due to users attempting to access a file in the dropbox. The two users are trying to read and write at the same time. We will implement the solution using Erlang programming language through which users will be able to access the same file without any concurrency issue arising. Erlang is a useful programming language that has been planned to the point of improving concurrent programming.Sequential programs when rendered have a single stream of operations, unlike concurrent programs. The concept of concurrent programs is opposite. There are numerous streams of operations executing together, and each stream of operation behaves like sequential programs. This nature of concurrent programs is very oppressive as multiple streams of actions communicate with each other as well as interfere with one another.To analyze the concurrency issue arises when users are trying to access the same file in a dropbox for different operations, we will try to access a file for a reading operation and another file for write operation simultaneously. After this, we will be finding possible solutions as to implement mutual exclusion. In the solution, we will handle the situation by prioritizing one of the processes so that the highly prioritized project complete its execution before the other one started to execute. This approach can be achieved through semaphore. To achieve the objective, we have to make sure that the objects have mutex access. A mutex is a synchronization object provided by the Erlang programming language, “mutexes are ordinarily used to shield a mutual asset from concurrent access. An errand seizes (or procures) the mutex, at that point gets to the asset, and after that discharges the mutex.”.In this paper, the background to the Dropbox service and Erlang programming language will be provided with the concurrency problem itself. After describing the background, will we address some approaches to solve the given problem? We will also explain the pros and cons of every approach. Then the decided approach will be implemented, the description of every step will be provided. Then we will move towards a conclusion by summarizing the problem and its solution discussed in this paper.BACKGROUNDA. What is Dropbox Service?Dropbox cloud storage is a standout amongst the best and helpful instruments accessible online today and is from numerous points of view the initial phase of cloud computing. Genuine could computing suggests that a PC comprises of just a mouse, console, screen, and web association. All data that would ordinarily be hung on a PC’s hard drive is kept inside the web. Cloud computing includes next to no product or information on the real PC. Everything is performed on through the web program on a system of PCs that are “in the cloud.” This large-scale level cloud computing is a moderately new idea. Be that as it may, little scale “small scale” cloud computing has existed for quite a long while. Dropbox cloud storage is a case of miniaturized scale cloud computing.Clients can store information in an online framework and afterward get to that information from any area with web get to. Dropbox enables clients to accumulate to 2 gigs of any information, for example, records or music documents, for nothing in an online storage framework. Clients can access their accounts and retrieve documents through any device provided with the internet connection. The Dropbox storage is like an external hard drive that can be accessed through any gadget such as smartphone, tablets, laptops, and PCs.B. What is Erlang Programming language?Erlang is a useful programming language which likewise has a runtime domain. It was worded such that it had incorporated help for simultaneousness, dissemination, and adaptation to non-critical failure. Erlang was initially created to be utilized as a part of a few expansive media transmission frameworks from Ericsson.The principal rendition of Erlang was produced by Joe Armstrong, Robert Virding and Mike Williams in 1986. It was initially a restrictive language inside Ericsson. It was later discharged as an open source language in the year 1998. Erlang, alongside OTP, an accumulation of middleware and libraries in Erlang, is presently upheld and kept up by the OTP item unit at Ericsson and alluded to as Erlang/OTP.C. Concurrency ProblemTo describe the concurrency problem, we will analyze two scenarios: bank and DropBox.A. Bank:In this example, the amount is deposited into a bank account by using Erlang programming language.depositA( Amount ) ->old_balance = get_balance(),new_balance = old_balance + Amount,set_balance( new_balance ).The argument Amount is passed in a method depositA(), the argument is specified by the user. After this, the remaining balance in the account will be assigned to a variable old_balance. The new balance will be equal to the old_balance and the Amount specified by the user. The calculated value will be stores in the new_balance variable. Now the amount will be deposited in a bank using set_balance()method which will take new_balance variable and increment the balance of the account. Now lets see how concurrency issue arise in this simple process. Lets take an example for User_A through a labelled transition system ( LTS).set_balance().Aget_balance().Aget_bal.Aset_bal.A210Similarly, User_B will complete its process in the same way as a User_A.1get_balance().Bset_balance().B02Now lets assume that the current balance of the bank account is 0 and User_A is rendering the method depositA( 20 ) and in the same time the User_B is busy in executing the function named as depositA(40). In the perfect scenario, the process will be like the following:Balance 0 -> get_balance.A 0 ->set_balance.A 20 -> get_balance.B 20 -> set_balance.B 40In the above scenario the new account balance will be 60. The balance of 10 was deposited by the User_A followed by User_B whoc deposited balance 40 in the account calculating the accurate balance in the end.Balance 0 -> get_balance.A 0 ->set_balance.B 10 -> get_balance.B 30 -> set_balance.A 10The balance will be just 10 in the above scenario. After amount 40 is deposit in the account because of the concurrency issues the account balance has a shortfall of 30 and this is not accepted in any condition.B. Accessing files residing in a DropBox:Lets analyze an example of accessing a file in drop box for read operation using Erlang programming language.read_file(filename) ->{ok, File}=file:opem(filename,[read]),txt= file:read(File,1024*1024).The function read_file() will take a filename as an argument specified by the users. The process then uses the filename and try to open the file with the same name. If the name exists then the relevant file with the read mode will be opened for reading purpose.The user can also access file for writing purpose which is implemented by using Erlang as follows:Write_file(filename,data)->{ok, File}=file:opem(filename,[read]),file:write(File,data).The function write_file() will takes filename and data as an argument. The data is the content which a user wants to write in a file specified by the user itself.Now let’s analyze the concurrency issue arising which will complicate the things in the simple scenario. The scenario can be described by the Finite state machine:Read/writeFreeIn the above FSM, it is obvious that the file or resource will be treated as free and any user can read or write on file simultaneously which ultimately generates the concurrency issue. The following FSM will show the system without any concurrency issue.ReadwriteFree BusySignalIn the concurrence free scenario, we will prioritize the write operation, when the user writes something in a file, then the resource will be in a busy state and will be unavailable until it is set free. The user can read or write in a free state. Now let’s analyze the approaches to solve the concurrency problem in a Dropbox.ApproachesWe will analyze the pros and cons of the following approaches:A. Mutex And SemaphoresAs expressed before a mutex is a significant choice as to deal with against simultaneousness issues, this execution includes the property the one process should finished first the another process will begin its execution. A semaphore executes such behavior by structuring and assembling the processes which are going to use the same resource.An issue which can emerge is a state called a deadlock, which if not focused against in the first code can cause issues for the framework. “A deadlock is an unintended condition under which various activities are stuck on some synchronization crude sitting tight for each other to continue.”B. Asynchronous message passingMessage passing if done effectively can make every one of the exchanges engaged with a saving money framework nuclear, implying that an exchange must act totally or not in any way, giving no halfway outcomes.The primary issue with this situation originates from a crash on the framework, either locally or through not including parameters when the framework gets a blunder.IMPLEMENTATIONWe will try to implement both the approaches: The message passing technique on the bank example and mutex and semaphore approach on accessing the file in a drop box.To apply message passing technique , we need to alter read-modify-write process of the old deposit method. The older deposit function is modified by adding more parameters for instance user could not withdraw the amount when the balance is negative or the account method should do the calculations and then providing the deposit method OK signal to finish the process.depositB ( Amount ) ->account_process ! {deposit, Amount, self()},receive{deposit, Amount, new_Balance} ->{ok, new_Balance} end.As it is obvious the deposit method is modified significantly. In the above function code, the process identifier (PID) has been assigned to account_process. It is also important to the know the meaning of symbol ‘!’ shows the send followed by the message. The account method provide the new balance to account signaling the Ok and exhibiting the account balance is refreshed. This technique wont allow processes to interfere into each other because both setter and getter methods are defined inside the account method.Moving onto the account procedure itself you can see that with the utilization of message passing the greater part of the calculations are done inside the capacity itself, guaranteeing that the procedure is nuclear, enabling us to totally discount any probability of further simultaneousness issues as the one expressed.account(Balance) ->receive{ set, new_Balance } ->account( new_Balance );{ get, From } ->From ! { balance, Balance },account( Balance );{ deposit, Amount, From } ->New_Balance = Balance + Amount,From ! {deposit, Amount, new_Balance},account( new_Balance )stop -> okend.As should be obvious when { deposit, Amount, From } is gotten by the account() process it will finish the calculations, refresh the account and send back the refreshed adjust to be gotten and giving it the all obvious from inside the deposit method.—————————————————- fileAccessing.erl —————————————————-module(fileAccessing).-export([fileAccessed/1, start/0, stop/0, read_file/0, write_file/1]).fileAccessed( FileName ) ->receive{write, From, Data} ->ok = file:write_file(FileName, Data),From ! ok,file(FileName);{read, From} ->{ok, Data} = file:read_file( FileName ),From ! Data,file( FileName );stop -> okend.start() ->File_PID = spawn( file, file, [“somefile.txt”] ),registe0r( file_process, File_PID ). stop() ->file_process ! stop,unregister(file_process).read_file (filename) ->{ok, File}=file:opem(filename,[read]),txt= file:read(File,1024*1024).Write_file (filename,data) ->{ok, File}=file:opem(filename,[read]),file:write(File,data).——————————————————- mutextest.erl———————————————————–-module(mutextest).-export([start/0, user/1]).start() ->fileAccessing:start(),mutex:start(),register(tester_process, self()),loop(10, 20, 100),unregister(tester_process),mutex:stop(),fileAccessing:stop().loop(_, _, 0) ->true;fileAccessing:read_file( filename ),spawn( fileAccessingtest, user, [filename] ),spawn( fileAccessingtest, user, [filename] ),receivedone -> trueend,receivedone -> trueend.user( filename ) ->fileAccessing:write_file( filename ),tester_process ! done.CONCLUSIONWe have analyzed the concurrency issue occurred in Dropbox. The issue was when one or more users attempt to access the same file, that is one user try to open a file in reading mode, and another one opens a file for writing purpose, this results in concurrency. We have analyzed the possible solutions required to solve these issue. Mutex and semaphore and applying asynchronous messages for atomic transactions are some possible solutions for this problem. We adopted mutex technique to solve the concurrency issue in Dropbox. We have implemented mutex solution in Erlang programming language. It is a fundamental programming language suitable developing application or system which may require concurrent operations.

Warning! This essay is not original. Get 100% unique essay within 45 seconds!


We can write your paper just for 11.99$

i want to copy...

This essay has been submitted by a student and contain not unique content

People also read