How can I make my queue thead-safe(concurrent) at F# - f#

Question

I made a data structure looks like queue at F#, which I'm not sure whether I can call it "queue" since it can randomely access at middle of sequence and edit it.
type item =
{
name : string
mutable point : int
}
type Queue = class
val mutable q : item []
new () = { q = Array.empty; }
member this.enq i =
let mutable b = true
try
this.q <- Array.append this.q [|i|]
with
| _ as e -> (b <- false)
b
member this.deq (i : byref<item>) =
let mutable b = true
try
i <- this.q.[0]
this.q <- Array.sub this.q 1 (this.q.Length - 1)
with
| _ as e -> (b <- false)
b
member this.edit p idx =
let mutable b = true
try
this.q.[idx].point <- p
with
| _ as e -> (b <- false)
b
member this.print =
let mutable b = true
try
for j = 0 to (this.q.Length - 1) do
printfn "%s %i" this.q.[j].name this.q.[j].point
with
| _ as e -> (b <- false)
b
end
so how can I make my something-looks-like-queue thread-safe?

Answer 1

In addition to the answers given by Just another metaprogrammer, one way that I've handled "I need a thread-safe version of X" in F# is to just put it behind a Mailbox Processor. The mailbox processor can ensure that things process in-order, one-at-a-time, so you don't have to worry about the concurrency. While using immutable data types and the algorithms that go along with them is certainly preferable, sometimes you're stuck needing to use a type or algorithm that supports mutation, and in those cases, I like to 'protect' that thing with a MailboxProcessor, making it the mailbox processor's private state, where nothing else can access it. Then, the consumers who need to use it go through the mailbox processor to do so, and the mailbox processor ensures that the consumers don't mess each other up.
For your case, you could do something like this:
type private QueueMessage<'a> =
| Enqueue of 'a
| Dequeue of AsyncReplyChannel<'a>
| Edit of int * ('a -> unit)
type SafeQueue<'a> () as this =
let agent =
MailboxProcessor<QueueMessage<'a>>.Start
<| fun inbox ->
let rec loop queue =
async {
let! message = inbox.Receive()
match message with
| Enqueue item ->
let newState = queue.enqueue item
return! loop newState
| Dequeue channel ->
let item = queue.dequeue()
channel.Reply item
return! loop queue
| Edit (idx, f) ->
f <| queue.[idx]
return! loop queue
}
loop <| new Queue<'a>()
let enqueue item =
agent.Post <| Enqueue item
let dequeue () =
agent.PostAndReply Dequeue
let edit idx f =
agent.Post(Edit (idx, f))
member __.Enqueue item = enqueue item
member __.Dequeue () = dequeue ()
member __.Edit (idx, f) = edit idx f

Answer 2

Seems OP is asking for a thread-safe queue that supports enqueue, dequeue and update.
Thread-safe can mean many things, for example should the operations be blocking (ie when dequeueing and empty queue). Are locks acceptable or not?
An approach that can be taken is implementing a thread-safe mutable queue using locks and ResizeArray. The idea is that ResizeArray is the backing data structure and then there's a lock object that is used to coordinate all access to the ResizeArray so that only one thread can can access it at any time and that also prevents memory reordering.
An example of a lockful queue using ResizeArray, no guarantees for correctness given, these things are tricky:
// A Queue is a pair of ResizeArray and a object that serve as the lock
type Queue<'T> = Q of ResizeArray<'T>*obj
// Creates a queue with an initial capacity
let create capacity =
let q = ResizeArray<'T>()
q.Capacity <- capacity
Q (q, obj ())
// enqueue uses lock on the lock object to ensure all access to the
// ResizeArray is coordinated so that only one thread can update it at a time.
// When inside the lock we add the element to the queue
let enqueue v (Q (q, l)) = lock l <| fun () -> q.Add v
// Same idea as with dequeue but inside the lock we removes the first element
// and returns it
let dequeue (Q (q, l)) = lock l <| fun () ->
if q.Count > 0 then
let v = q.[0]
q.RemoveAt 0 // This is not an efficient dequeue as it's O(n), use an example only
Some v
else
None
// As with enqueue and dequeue the update operation wait till under the lock
// to update the queue. Note; this likely not a good pattern to do it as
// if there are multiple threads consuming and producing elements the index
// is likely wrong. Better to do an update operation that gets exclusive access
// to the ResizeArray to perfom it's operations
let update v i (Q (q, l)) = lock l <| fun () ->
if i < q.Count then
q.[i] <- v
else
raise (ArgumentOutOfRangeException "i")
let example () =
printfn "Using Locked Resize Array"
let q = create 10
enqueue 1 q
enqueue 2 q
enqueue 3 q
update 12 1 q
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
So getting this kind thread-safe code correct is tricky. In addition, the code above relies on locking which is can be bad for performance as it stalls threads.
Better is to use the built-in ConcurrentQueue. The drawback for OP is that this queue doesn't support update. The pros are many though as this queue requires no lock to be used safely. It's actually internally implemented using lock-free techniques to ensure that threads aren't stalled (in perverse scenarios one could imagine soft stalling of threads as threads are guaranteed to not stall but not guaranteed progress).
So if OP can live without the update function:
open System.Collections.Concurrent
type Queue<'T> = Q of ConcurrentQueue<'T>
let create () =
let q = ConcurrentQueue<'T> ()
Q q
// No need for any locks, as this is a thread-safe collection
let enqueue v (Q q) = q.Enqueue v
// No need for any locks, as this is a thread-safe collection
let dequeue (Q q) =
let b, v = q.TryDequeue ()
if b then Some v else None
let example () =
printfn "Using Concurrent Queue"
let q = create ()
enqueue 1 q
enqueue 2 q
enqueue 3 q
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
printfn "%A" <| (dequeue q)
Immutable collections were mentioned as a possible approach and that is certainly possible but the purpose of the thread-safe queue is likely that it should be shared and processed by multiple threads. That shared binding needs to mutable to allow enqueue and dequeue as an immutable (sometimes called persistent) data structure never change, enqueue and dequeue produces a new queue.
The code that updates still need consider what happens when multiple threads read and updates the mutable binding.
Simply overwriting the mutable binding with a new queue might cause double processing of queue elements, lost elements and undefined behavior because memory reordering issues, all of these issues are very hard to debug even more so because they are likely rare.
It's fixable though by ensure the mutable binding is updated under a lock or in lock-free CAS loop.
open System
open System.Threading
// Very simplistic immutable queue that consists of two lists
// The first list is being dequeued from
// The second list is being enqueued to
// When the first list is empty, the second list reversed and becomes the new first list
// The book Purely Functional Data Structures by Chris Okasaki dedicates large part
// of the book to explore many variants on how to implement more efficient
// immutable queues
type Queue<'T> = Q of 'T list*'T list
[<GeneralizableValue>]
let empty<'T> = Q ([], [])
// enqueue "cons" the value to the back list
let enqueue v (Q (f, b)) = Q (f, v::b)
// dequeue tries to take the head of the front list
// if the front the list is empty, reverse the back list
// that becomes the front list
let rec dequeue (Q (f, b)) =
match f,b with
| [] , [] -> None, empty
| h::t , _ -> Some h, Q (t, b)
| [] , h::t-> Some h, Q (List.rev t, [])
module Details =
module Loops =
// Uses a CAS loop too update the state
// Might cause the updater function to be evaluated many times
// so important that the updater function is pure and fast
let rec lockfreeUpdate (q : byref<'T>) updater current =
let v, next = updater current
let actual = Interlocked.CompareExchange<'T> (&q, next, current)
if Object.ReferenceEquals (actual, current) then
v
else
lockfreeUpdate &q updater actual
open Details
// Updates the mutable binding using a lock free CAS loop
let inline lockfreeUpdate (q : byref<_>) updater = Loops.lockfreeUpdate &q updater (Volatile.Read &q)
// Updates the mutable binding under a lock
let inline lockfulUpdate (q : byref<_>) l updater =
Monitor.Enter l
try
let v, qq = updater q
q <- qq
v
finally
Monitor.Exit l
let example () =
printfn "Using ImmutableQueue"
let l = obj ()
let mutable q = empty
lockfreeUpdate &q l (fun q -> (), enqueue 1 q)
lockfreeUpdate &q l (fun q -> (), enqueue 2 q)
lockfreeUpdate &q l (fun q -> (), enqueue 3 q)
printfn "%A" <| (lockfreeUpdate &q dequeue)
printfn "%A" <| (lockfreeUpdate &q dequeue)
printfn "%A" <| (lockfreeUpdate &q dequeue)
printfn "%A" <| (lockfreeUpdate &q dequeue)
Hope this serves as some inspiration on how to solve the problem you have. Note, getting thread-safe code right is tricky so I encourage finding a collection under System.Collections.Concurrent that has the right behavior for you.
It's very tempting to try to get "cute" but the problem with buggy concurrent code is that the buggy code will go through all unit tests, all integration tests and the system tests. After a while one receives bug reports about product instabilities that can't be reproduced.