locked
Why isn't the ThreadStatic attribute allowed in portable libraries? RRS feed

  • Question

  • I'm trying to define a field in a class in my portable library with the [ThreadStatic] attribute but it won't compile. It says the attribute is not defined. This attribute is supported in each of the platforms that my portable library is configured to support (.NET, Silverlight, Phone, Tailored). Is this just an oversight in the portable library support? Is there any workaround? What are the chances of a fix before the release of VisualStudio?
    Tuesday, October 4, 2011 4:27 PM

Answers

  • We support in the Beta when you are not targeting Phone or Xbox.

    Base Class Library Team (BCL) | My Blog: http://davesbox.com

    Thursday, April 12, 2012 3:37 PM
  • Apologies for the late reply I thought I had responded.

    Thanks for trying out portable. ThreadStaticAttribute hasn't been included because currently it is not supported on Phone & Xbox. Even though Phone ships with the type, it doesn't actually work.

    The workaround would be to have some (threadsafe) dictionary that used Thread.CurrentThread.ManagedThreadId as the key and the instance as the value. Something like:

     

            private static readonly Dictionary<int, object> _instances = new Dictionary<int, object>();
    
            public static object ThreadStaticInstance
            {
                get
                {
                    lock (_instances)
                    {
                        object instance;
                        if (_instances.TryGetValue(Thread.CurrentThread.ManagedThreadId, out instance))
                        {
                            instance = new object();
                            _instances.Add(Thread.CurrentThread.ManagedThreadId, instance);
                        }
    
                        return instance;
                    }
                }
            }
    

    Clearly replacing 'object' above with whatever type you are interested in.

     

     


    Base Class Library Team (BCL) | My Blog: http://davesbox.com
    Wednesday, October 5, 2011 8:47 PM

All replies

  • Apologies for the late reply I thought I had responded.

    Thanks for trying out portable. ThreadStaticAttribute hasn't been included because currently it is not supported on Phone & Xbox. Even though Phone ships with the type, it doesn't actually work.

    The workaround would be to have some (threadsafe) dictionary that used Thread.CurrentThread.ManagedThreadId as the key and the instance as the value. Something like:

     

            private static readonly Dictionary<int, object> _instances = new Dictionary<int, object>();
    
            public static object ThreadStaticInstance
            {
                get
                {
                    lock (_instances)
                    {
                        object instance;
                        if (_instances.TryGetValue(Thread.CurrentThread.ManagedThreadId, out instance))
                        {
                            instance = new object();
                            _instances.Add(Thread.CurrentThread.ManagedThreadId, instance);
                        }
    
                        return instance;
                    }
                }
            }
    

    Clearly replacing 'object' above with whatever type you are interested in.

     

     


    Base Class Library Team (BCL) | My Blog: http://davesbox.com
    Wednesday, October 5, 2011 8:47 PM
  • If I turn off phone and only target .NET, Silverlight and Tailored which do all support this feature, then I should be able to compile. It does not. So why is my portable library limited by the functionality of platforms that I have turned off?

    Our software is highly multi-threaded and largely we manage those threads ourselves.  Between ThreadStatic, no Thread constructor and Dispatcher differences in Metro it would require architectural changes to take advantage of portable libraries.

    If we could implement lower level abstractions in platform specific assemblies then build portable assemblies on top, that would work. Of course that is not an option either because portable libraries can only reference portable libraries. If we could provide an assembly for each platform and have VisualStudio present the intersection of the types to the portable library, it would allow much more flexibility.

    Wednesday, October 5, 2011 11:05 PM
  • If your application is very thread-based, with or without portable you will need to make changes to move over to metro (we incorrectly call it 'Tailored' in portable at the moment). The fact that ThreadStaticAttribute isn't available in the .NET, Silverlight, Tailored intersection is a bug, and I've filed a work item to add it.

    How you approach this (with or without ThreadStatic) might vary based on how your application is designed at the moment. Before I suggest an approach, are you using any type of IoC/Dependency Injection or service provider-like framework at the moment?

     

     

     


    Base Class Library Team (BCL) | My Blog: http://davesbox.com
    Thursday, October 6, 2011 12:39 AM
  • Our application is actually a development environment. We allow our customers to define a program in our editor and we generate it into multi-threaded CLR code. To make the code generation easier, we have a small set of assemblies that provide helper functionality. The focus for these assemblies is small and efficient. We want to keep our runtime dependencies to a minimum.

    We use MEF in our editor so I can see how something like that would allow more of the code to be in portable libraries. But that approach still relies on having some platform specific assemblies to provide a common abstraction for each platform.

    If we could give our customers a portable distribution for non-UI code, then that would be a marketable feature. However, if their assembly depends on platform specific assemblies then we haven't really delivered that. They would still have to deploy different files on each platform.

    There may be places we can take advantage of portable libraries within our editor, but for our runtime assemblies we'll probably just stick with our current approach which shares source between separate builds for each platform.

    Thursday, October 6, 2011 3:33 AM
  • I would love to talk about your scenario more (it sounds very similar to what a team internally are doing).

    Can you email me david.kean AT Microsoft DOT com?


    Base Class Library Team (BCL) | My Blog: http://davesbox.com
    Thursday, October 6, 2011 4:37 AM
  • So, will you implement it in the next version of PCL?
    Thursday, April 12, 2012 1:24 PM
  • We support in the Beta when you are not targeting Phone or Xbox.

    Base Class Library Team (BCL) | My Blog: http://davesbox.com

    Thursday, April 12, 2012 3:37 PM
  • Targeting Windows Phone is what I need.

    So for now is better to just create 3 projects (Desktop, Silverlight, Phone). And everithing builds very well.

    It is interesting, what is the problem with this attribute in PCL.

    Tuesday, April 17, 2012 8:21 AM
  • Portable Class Libraries try to present a view of the APIs that is compatible across all the frameworks. Windows Phone 7.x do not support this attribute, and ignore it. If you were to rely on it, then you would be very surprised when your library behaved differently on Phone than it does on the other platforms.

    Base Class Library Team (BCL) | My Blog: http://davesbox.com

    Tuesday, April 17, 2012 2:37 PM
  • must be

    if (_instances.TryGetValue(Thread.CurrentThread.ManagedThreadId, out instance) == false)

    Wednesday, August 15, 2012 3:31 PM