Research on Controlling Concurrency in Real-Time Application (PART IV)

Dropbox Locking

The traditional way of handling concurrency involves using low-level programming constructs and techniques. It’s important to note that traditional concurrency handling approaches manual management of synchronization and coordination, which can be error-prone and at times complex, and potentially often requires careful consideration of shared data access, synchronization primitives, and potential race conditions. Modern concurrency frameworks and libraries have emerged to simplify concurrency management and provide higher-level abstractions for concurrent programming.

First, we need to discuss the traditional of handling concurrency;

• Threads — Threads are a fundamental unit of concurrent execution in traditional concurrency handling. Developers create multiple threads within a program, and each thread represents an independent flow of execution. Threads can run concurrently and perform different tasks simultaneously. However, managing threads manually requires careful consideration of synchronization and coordination to avoid race conditions and ensure data integrity.
• Locks and Mutexes — Locks and mutexes are synchronization primitives used to provide mutual exclusion and control access to shared resources. Developers use locks or mutexes to protect critical sections of code, ensuring that only one thread can access the shared resource at a time. Locking and unlocking the mutex guarantees exclusive access, preventing race conditions and maintaining data consistency.
• Read-Write Locks — Read-write locks provide a mechanism to manage concurrent read and write access to shared resources. Multiple threads can simultaneously acquire the read lock, allowing concurrent read access. However, write access is exclusive, requiring exclusive ownership of the write lock. Read-write locks are useful when the majority of operations are read, and the number of write operations is limited.

In the case of Dropbox, this is quite different because the distributed systems do not include only computers but humans as well. In this section, we will argue if people can be more tolerant of concurrence problems than computers. The upcoming sub-section will illustrate the effects of neglecting concurrency in real-time applications. Two examples would be enough. First, Dropbox HelloDoc software, help us to create, manipulate, and edit document, word text, drawings, etc. Second, consider the Dropbox DocSend, which allows multiple users to enter and manipulate text at the same time. Both examples show, two users; each with their own cursor on the display, When working with a Dropbox HelloDoc, it would be rude to scribble over another’s marks as they’re writing them or engage in a tug of war over a pen. In case, situations arise, such as;

• Accidental inference due to one person not noticing what the other is working on
• Intentional changing of controls

Our point is that, in many Dropbox applications, concurrency problems may be rare because individuals mediate interactions themselves. When conflicts happen, they may not be problematic in practice. When people notice conflicts and problems, they are often quite capable of repairing their negative effects and consider it part of the natural dialog. The computer role can thus be seen as one that provides enough feedback and affordances of shared objects to support people’s natural abilities. If computer-mediated concurrency control is used, it just becomes a way of avoiding or recovering from rare conflicts.

Examples of related work, The COLAB face-to-face meeting tool used visual feedback to show which screen objects were “busy”. If an object was selected by a participant, it would be grayed out, acting as a busy signal to inform others to leave you alone. Whimsical is a shared drawing system designed for small and large teams. Its engineers also noticed that conflicts are rare events and usually result in minor consequences. Still, they’re worried about its concurrency. Because of the simplicity of how they treat shared drawings across all platforms, they decided to treat drawing strokes as “immutable objects”. If an object is subject to concurrent operations, a new object is spawned so that each user is working on their own copy. This is a technical solution, since both sites are consistent but also a human, solution because people see the copies and repair the drawing if needed.

Dropbox Locking

This aspect guarantees that individuals access objects in the shared workspace one at a time. The problem is the grain size of the lock, the delays in acquiring a lock, and the effects of optimism. Different grain sizes give a different feel to Dropbox. The grain size of a lock determines how little an object when displayed is managed by a single lock. From a system’s perspective, coarse granularity implies fewer lock requests, with less opportunity for concurrency as locks will be denied more frequently. This is true for grained locks. Problems arise when there is no balance between a locking overhead and the number of concurrencies requested.

A single lock on a document forces individuals to revert to a serial interaction model with a computer-mediated turn-uiking protocol, which is a popular thought for collaborating transparently with other systems that allow the unaltered single-user application to be shared with various people. However, most engineers at Dropbox think simultaneous access to the view is paramount to natural interaction. The drawing package on Dropbox can have locks on a set of objects(multiple), or a single object(the linked or the stroke), and even on a single handle of the object. For instance, when the lock is on the handle, then two individuals could grab different endpoints and collectively move and resize it. If locking is at the object level, then the richness of the interaction is not actualized. Likewise, Text-editors such as Visual Studio code, I think the coarser the lock the harder it will become to work with it. Extra care should be taken when using a lock. users often use this as a form of gesture on the editor, the locking mechanism has made this impossible. Locks are expected to be user-friendly, in the sense, pending locks are not desirable. For example, a user will select an object and then stopped from proceeding until the lock is granted. If delays are barely noticeable, this may not mean a lot. However, will interfere with the flow of interaction. Delays make the interface look unresponsive. The interface is expected to provide feedback displaying that the object, is pending, for a lock request to be served(e.g. a selection of a shape), which deals with its state.

Most times there are things to consider as an application developer when choosing a locking scheme for an application. You expect the lock to be instantaneous when receiving requests, and when the network fails or processors suffer a visible delay, the lock should interpret it as a poor interface for the user to see. When developing a sensitive interface, locking might be hard to control. Consider the following below;

• An individual manipulate various object on the same application, all of which possess locks, in sequence. For instance, consider a group of drawings in sequence. The individual first moves a circle, then a line inside of the circle, and eventually shifts his/her attention to a different part of the view. Later, the lock on the line is denied. Now a question, should only the line be snapped back, or should the entire sequence be undone? will the user know if it’s because her lock has been denied?
• Consider a scenario where two people are grabbing a line, each with a lock. Should each of them see their copy, when moving the line around? if so, we might decide not to transmit object manipulations until a lock is granted.

The locking algorithm can take several forms and is implemented in a network layer. This layer provides the lock layer with communication among the conference applications. The lock layer asks the network layer if there are any other lock holders. The developer needs to know everything about the network layer, the advantage is that various underlying locking algorithms can be used.

TO BE CONTINUED…