Feature Request: Improve Shared State Handling with Thread-Safe Structures

[mdaneri]

Summary

The current Pode implementation requires explicit locking via Lock-PodeObject for all shared state variables, as it primarily supports non-thread-safe data structures. This can lead to performance bottlenecks and unnecessary complexity when managing shared state across multiple runspaces. This feature request proposes adding support for natively thread-safe structures to improve performance and reduce the need for manual locking.

---

Problem Statement

• Lack of Thread-Safe Data Structures:
  Pode currently does not differentiate between thread-safe and non-thread-safe shared state objects.
• Forced Use of Lock-PodeObject:
  Users must explicitly use Lock-PodeObject even when working with inherently thread-safe collections, which adds complexity and potential overhead.
• Performance Bottlenecks:
  Unnecessary locking can lead to performance degradation, especially in high-concurrency environments.

---

Proposed Solution

1. Introduce Native Support for Thread-Safe Collections:
   Pode should natively support the following thread-safe structures, eliminating the need for Lock-PodeObject:

   • ConcurrentDictionary
   • ConcurrentBag
   • ConcurrentQueue
   • ConcurrentStack

2. Retain Support for Non-Thread-Safe Structures with Explicit Locking:

   • Hashtable, OrderedDictionary, and PSCustomObject should continue requiring Lock-PodeObject to ensure safe concurrent access.

3. Enhance Documentation and Provide Clear Examples:

   • Update Pode's documentation to specify which structures are thread-safe and which require explicit locking.
   • Provide best practices and code examples demonstrating correct usage.

---

Benefits

• Performance Improvement: Reduces unnecessary locking and execution overhead.
• Simplified Code: Developers no longer need to manually lock inherently thread-safe objects.
• Better Stability: Reduces the risk of concurrency issues and race conditions.
• Backward Compatibility: Ensures that existing Pode applications using Lock-PodeObject will continue to function without modification.

---

Example Scenario

Current Approach (Requires Manual Locking)

Start-PodeServer {
    Add-PodeTimer -Name 'update-data' -Interval 5 -ScriptBlock {
        Lock-PodeObject -ScriptBlock {
            Set-PodeState -Name 'data' -Value @{ 'Name' = 'Rick Sanchez' } | Out-Null
        }
    }
}

Proposed Approach (Thread-Safe Objects Require No Locking)

Start-PodeServer {
    Add-PodeTimer -Name 'update-data' -Interval 5 -ScriptBlock {
        Set-PodeState -Name 'data' -Value ([System.Collections.Concurrent.ConcurrentDictionary[string, string]]::new()) | Out-Null
    }
}

---

Impact & Considerations

• Backward Compatible: All existing Pode implementations will continue to work without modification.
• Performance Gains: Eliminates unnecessary locking, improving execution efficiency.
• Clearer Best Practices: Helps developers make informed decisions on when locking is required.