JS `Web Locks API` `Mode` (`shared`/`exclusive`) `Starvation` 与 `Deadlock` 避免

Alright folks, gather ’round! Let’s talk about Web Locks API, and how to avoid turning your web apps into traffic jams of starvation and deadlock. Think of me as your friendly neighborhood JavaScript traffic controller, here to keep things moving smoothly.

Introduction: What are Web Locks, Anyway?

Imagine you’re building a collaborative document editor. Two users, Alice and Bob, are furiously typing away. Without some sort of coordination, you could end up with a garbled mess where Alice’s changes overwrite Bob’s, or vice versa.

That’s where the Web Locks API comes in. It’s a mechanism for coordinating access to shared resources in a way that prevents conflicts. It’s like a digital lockbox: only one piece of code can hold the key (the lock) at any given time. This allows you to safely modify shared data, update UI elements, or perform other critical operations without stepping on anyone else’s toes.

The Basics: navigator.locks

The Web Locks API revolves around the navigator.locks object. This object provides methods for requesting and releasing locks. The main players are:

• request(name, options, callback): Requests a lock with the given name.
  • name: A string that identifies the resource you want to lock. It’s like the label on the lockbox.
  • options: An optional object to configure the lock.
    • mode: Specifies the lock mode ("shared" or "exclusive"). We’ll dive into this shortly.
    • ifAvailable: A boolean. If true, the callback executes immediately if the lock is available, otherwise it returns null. The callback is not executed if the lock is not immediately available.
    • steal: A boolean. If true, and the lock is held by another context with a lower priority, the lock will be stolen. Requires the mode to be "exclusive".
  • callback: A function that will be executed if and when the lock is granted. When the callback finishes (either by returning or throwing an error), the lock is automatically released. You can also manually release the lock if required.
• query(): Returns a Promise that resolves with an object containing information about the currently held and pending locks.

Lock Modes: Shared vs. Exclusive

The mode option determines how the lock can be used. There are two flavors:

• "exclusive": This is your standard, "one at a time" lock. Only one piece of code can hold an exclusive lock on a given resource. Think of it as a single key for the lockbox. This is great for operations that need to be atomic, like writing to a database.
• "shared": Multiple pieces of code can hold a shared lock on the same resource simultaneously. Think of it as a bunch of people reading a document at the same time. This is suitable for operations that are read-only and don’t modify the underlying data.

Here’s a table to summarize:

Mode	Multiple Holders?	Use Case
"exclusive"	No	Writing to a database, updating critical UI elements, modifying shared state
"shared"	Yes	Reading data, performing calculations based on shared data

Example: Exclusive Lock

async function updateCounter() {
  try {
    await navigator.locks.request('counter', { mode: 'exclusive' }, async (lock) => {
      // Simulate reading the current value (e.g., from localStorage)
      let counterValue = parseInt(localStorage.getItem('counter') || '0');

      // Increment the counter
      counterValue++;

      // Simulate a slow operation
      await new Promise(resolve => setTimeout(resolve, 1000));

      // Update the value (e.g., to localStorage)
      localStorage.setItem('counter', counterValue.toString());

      console.log('Counter updated to:', counterValue);

      // The lock is automatically released when this callback finishes.
    });
  } catch (error) {
    console.error('Failed to acquire lock or update counter:', error);
  }
}

// Call this function from multiple places in your code.
updateCounter();

In this example, only one call to updateCounter can execute the code inside the callback at a time. If another call to updateCounter happens while the lock is held, it will wait until the first call releases the lock.

Example: Shared Lock

async function displayCounter() {
  try {
    await navigator.locks.request('counter', { mode: 'shared' }, async (lock) => {
      // Simulate reading the current value (e.g., from localStorage)
      let counterValue = parseInt(localStorage.getItem('counter') || '0');

      console.log('Counter value:', counterValue);

      // Simulate a short read operation
      await new Promise(resolve => setTimeout(resolve, 500));

      // The lock is automatically released when this callback finishes.
    });
  } catch (error) {
    console.error('Failed to acquire lock or read counter:', error);
  }
}

// Call this function from multiple places in your code.
displayCounter();

Multiple calls to displayCounter can execute concurrently because they are only reading the counter value. They don’t need exclusive access.

The Perils of Concurrency: Starvation and Deadlock

Now, let’s talk about the dark side of concurrency: starvation and deadlock. These are the boogeymen that can turn your beautiful, concurrent code into a frozen, unresponsive mess.

• Starvation: This happens when a piece of code is perpetually denied access to a shared resource, even though it’s constantly requesting it. It’s like being stuck in a never-ending waiting line. Imagine a scenario where you have a resource, and threads A and B are competing for it. If thread A consistently acquires the resource before thread B can, thread B might never get a chance to use it, leading to starvation.

• Deadlock: This is a more dramatic situation where two or more pieces of code are blocked indefinitely, waiting for each other to release resources. It’s like two cars blocking each other in an intersection – nobody can move. Imagine thread A holds lock X and is waiting for lock Y, while thread B holds lock Y and is waiting for lock X. Neither can proceed, and you’ve got a deadlock.

Avoiding Starvation

Here are some strategies to prevent starvation when using the Web Locks API:

1. Fairness: While the Web Locks API doesn’t guarantee strict fairness (first-come, first-served), strive for fairness in your code. Avoid holding locks for excessively long periods. The shorter you hold a lock, the more opportunities other code has to acquire it.

2. Prioritization: If you have tasks with different priorities, consider implementing a mechanism to prioritize lock requests. However, be careful! Poorly implemented prioritization can actually cause starvation for lower-priority tasks. The steal option available on exclusive locks can be used, but be careful using it because it can cause unexpected behavior.

3. Lock Granularity: Avoid locking large chunks of resources when you only need to access a small part. Finer-grained locking reduces contention and makes it less likely for code to be blocked.

Avoiding Deadlock

Deadlock is a more insidious problem. Here’s how to avoid it:

1. Lock Ordering: The most common and effective technique is to establish a consistent order for acquiring locks. If all code acquires locks in the same order, you can prevent circular dependencies. For example, if you always acquire lock A before lock B, you can avoid the scenario where one piece of code is waiting for A while holding B, and another is waiting for B while holding A. This is often difficult in complex systems.

2. Timeout: Implement timeouts for lock requests. If a piece of code cannot acquire a lock within a reasonable time, it should release any locks it already holds and try again later. This breaks the circular dependency and allows other code to proceed. However, timeouts can be tricky because you need to choose a timeout value that’s long enough to allow legitimate operations to complete, but short enough to prevent excessive delays.

3. Lock Hierarchies: A lock hierarchy is a more structured approach to lock ordering. You define a hierarchy of locks, and code must acquire locks in ascending order within the hierarchy. This ensures that there are no cycles in the lock dependencies.

4. Avoid Nested Locks: Reduce nesting locks as much as possible. The deeper the nesting the higher the chance of deadlocks.

Practical Examples and Code Snippets

Let’s illustrate these concepts with some more practical examples.

Example: Timeout for Lock Acquisition

async function updateCounterWithTimeout(timeoutMs) {
  let lockAcquired = false;
  let timeoutId;

  try {
    await new Promise((resolve, reject) => {
      timeoutId = setTimeout(() => {
        reject(new Error('Failed to acquire lock within timeout'));
      }, timeoutMs);

      navigator.locks.request('counter', { mode: 'exclusive' }, async (lock) => {
        lockAcquired = true;
        clearTimeout(timeoutId); // Clear the timeout since we acquired the lock

        // Simulate reading the current value (e.g., from localStorage)
        let counterValue = parseInt(localStorage.getItem('counter') || '0');

        // Increment the counter
        counterValue++;

        // Simulate a slow operation
        await new Promise(resolve => setTimeout(resolve, 1000));

        // Update the value (e.g., to localStorage)
        localStorage.setItem('counter', counterValue.toString());

        console.log('Counter updated to:', counterValue);

        resolve(); // Resolve the promise when the lock is released
      }).catch(reject);
    });
  } catch (error) {
    console.error('Failed to acquire lock or update counter:', error);
  } finally {
    if (!lockAcquired && timeoutId) {
      clearTimeout(timeoutId); // Ensure the timeout is cleared if it wasn't already
    }
  }
}

// Call this function with a timeout value.
updateCounterWithTimeout(5000); // Timeout after 5 seconds

In this example, we use a Promise and a setTimeout to implement a timeout for lock acquisition. If the lock is not acquired within the specified timeout, the Promise is rejected, and the code handles the error. This prevents the code from being blocked indefinitely if the lock is unavailable.

Example: Lock Ordering

Let’s say you have two resources: userProfile and userSettings. To avoid deadlock, always acquire the locks in the same order:

async function updateUserProfileAndSettings(userId, profileData, settingsData) {
  try {
    // Acquire the userProfile lock first
    await navigator.locks.request(`userProfile-${userId}`, { mode: 'exclusive' }, async () => {
      console.log(`Acquired userProfile lock for user ${userId}`);

      // Then acquire the userSettings lock
      await navigator.locks.request(`userSettings-${userId}`, { mode: 'exclusive' }, async () => {
        console.log(`Acquired userSettings lock for user ${userId}`);

        // Simulate updating the user profile and settings
        await new Promise(resolve => setTimeout(resolve, 500));

        console.log(`Updated user profile and settings for user ${userId}`);
      });
    });
  } catch (error) {
    console.error(`Failed to update user profile and settings for user ${userId}:`, error);
  }
}

// Call this function to update both profile and settings.
updateUserProfileAndSettings(123, { name: 'New Name' }, { notificationsEnabled: true });

By always acquiring the userProfile lock before the userSettings lock, we prevent a deadlock scenario where one piece of code is waiting for userProfile while holding userSettings, and another is waiting for userSettings while holding userProfile.

Example: Using ifAvailable to Avoid Blocking

async function tryUpdateCounter() {
  try {
    const lock = await navigator.locks.request('counter', { mode: 'exclusive', ifAvailable: true }, async (lock) => {
      // Simulate reading the current value (e.g., from localStorage)
      let counterValue = parseInt(localStorage.getItem('counter') || '0');

      // Increment the counter
      counterValue++;

      // Simulate a slow operation
      await new Promise(resolve => setTimeout(resolve, 1000));

      // Update the value (e.g., to localStorage)
      localStorage.setItem('counter', counterValue.toString());

      console.log('Counter updated to:', counterValue);

      // The lock is automatically released when this callback finishes.
    });

    if (!lock) {
      console.log('Counter is currently being updated by another process. Skipping update.');
    }
  } catch (error) {
    console.error('Failed to acquire lock or update counter:', error);
  }
}

// Call this function from multiple places in your code.
tryUpdateCounter();

This example demonstrates how to use the ifAvailable option to avoid blocking if the lock is already held. If the lock is not immediately available, the callback is not executed, and the code logs a message indicating that the counter is currently being updated by another process. This can be useful in situations where you want to avoid waiting for the lock and instead perform some other action.

Debugging and Troubleshooting

Even with the best precautions, concurrency issues can still arise. Here are some tips for debugging and troubleshooting Web Locks API issues:

• navigator.locks.query(): Use this method to inspect the currently held and pending locks. This can help you identify which code is holding a lock and which code is waiting for it.

• Console Logging: Sprinkle your code with console logs to track lock acquisition and release. This can help you understand the flow of execution and identify potential deadlocks or starvation scenarios.

• Browser Developer Tools: Use the browser’s developer tools to inspect the state of your application and identify any unexpected behavior.

Conclusion: Locking Down Your Code

The Web Locks API is a powerful tool for managing concurrency in web applications. By understanding the concepts of shared and exclusive locks, and by implementing strategies to avoid starvation and deadlock, you can build robust and reliable concurrent code. Remember to keep your locks short, avoid nested locks, and always strive for fairness.

Now go forth and conquer the world of concurrency, my friends! And remember, a little bit of locking can go a long way towards preventing a whole lot of trouble.