Question

I need some help in understanding the thread safety in azure CloudBlobClient, CloudQueueClient and CloudBlob classes.

I am developing a worker role which includes multiple independent job processors where each of these job processors read from a specific queue and write/update to some blob containers which may be the same.

I want to make sure that these job processors are not stepping on each other toe.

1> How can I make sure that this is the case without using any kind of lock? If I assign a separate CloudBlobClient and CloudQueueClient to each of my job processors (who all live within same process), is it enough to say that they are independent from each other and because every job processors uses a separate client instance, they will not run into each other at all?

2> Within same job processor, if I try to have parallelism on CloudBlobClient using Parallel.ForEach to say call GetBlobReference or UploadText in parallel, do I need to incorporate some sort of synchronization or are these methods thread safe? Azure documentation says they are not but most examples that I have seen online do not seem to apply any kind of synchronization mechanism on these methods. What is the best way to achieve this? I mean the best way to use one CloudBlobClient and call GetBlobReference or UploadText in Parallel?

Answer 1

I had a look at the CloudBlobClient documentation on MSDN and what it says is:

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

As this is not a static member, it is not guaranteed to be thread safe. If you want to be sure that you’re not going to get caught out by any threading issues the MS may have missed in the storage client library, then yes you should ensure that each thread has it’s own client (maybe create a ThreadStatic variable).

Having said that, I have used the CloudBlobClient to upload multiple items in a Parallel.ForEach without it causing any problems.