9

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?

iCode
  • 4,308
  • 10
  • 44
  • 77

2 Answers2

3

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.

knightpfhor
  • 9,299
  • 3
  • 29
  • 42
  • 1
    But I kinda agree with Oliver as this is to be more of boiler plate comment. I couldn't find any reported issue on this except when you use a higher than one for ParallelOperationThreadCount. I prefer not to lock up the code if I don't have to. – iCode May 17 '11 at 02:22
  • You do see the comment about thread safety on pretty much every class in the framework. ParallelOperationThreadCount is used by the library to create threads internally, so this shouldn't affect what you're doing. The client classes are pretty light weight to create. – knightpfhor May 17 '11 at 03:16
2

The documentation for a randomly chosen function says "Any public static...members of this type are thread safe. Any instance members are not guaranteed to be thread safe.", but I would assume this is boilerplate put in because someone could not be bothered to think about it. I suggest you examine the classes using Reflector, but I would expect they would be fine because all the classes you refer to are just repositories for properties that end up being put into HTTP REST requests when you make a call like UploadText. So long as you do not change properties for one object in different threads (and I don't think you will need to - create a CloudBlobReference for each iteration of your Parrallel.ForEach) then I reckon you will be safe.

Oliver Bock
  • 4,829
  • 5
  • 38
  • 62
  • I agree with you as this could be more of a general statement. My reflector is not working any more and it is asking for my credit card number!! that's why I could not check it. Wish someone from the Azure team could clarify this. – iCode May 17 '11 at 02:25
  • Red Gate do now make an older version of Reflector available for free. Probably they do not make it easy to find. – Oliver Bock May 17 '11 at 05:05