Thread.Sleep() in a Portable Class Library

Question

The MSDN docs say Thread.Sleep() can be used in a portable class library. The compiler says otherwise. What are my alternatives besides a spin-loop? Thread.CurrentThread.Join() doesn't exist either.

Project file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{C46B138E-CC30-4397-B326-8DD019E3874B}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>x0xtest.AVR</RootNamespace>
    <AssemblyName>x0xtest.AVR</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <TargetFrameworkProfile>Profile3</TargetFrameworkProfile>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Core" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Attributes\AddressAttribute.cs" />
    <Compile Include="Attributes\RegAttribute.cs" />
    <Compile Include="Attributes\ROAttribute.cs" />
    <Compile Include="Attributes\RWAttribute.cs" />
    <Compile Include="Attributes\WOAttribute.cs" />
    <Compile Include="Devices\ATMega162.cs" />
    <Compile Include="Exceptions.cs" />
    <Compile Include="IntelHexFormat.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Proxy.cs" />
    <Compile Include="ProxyBase.cs" />
    <Compile Include="ProxyBase_UploadFirmware.cs" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\x0xtest.Comm\x0xtest.Comm.csproj">
      <Project>{F78547AC-1CA1-4ADB-9FA8-3E7DEB682240}</Project>
      <Name>x0xtest.Comm</Name>
    </ProjectReference>
  </ItemGroup>
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

Answer 1

This is the unfortunate side effect of "portable". A library becomes highly portable by subtraction, removing all the parts that are unavailable on just one of the many possible targets. That played havoc with the Thread class, it is quite devoid of any useful members. Just 5 of them left, MemoryBarrier(), CurrentCulture, CurrentThread, CurrentUICulture and ManagedThreadId.

This might look odd, the intersection of the advertized targets certainly support more. This is probably related to the un-advertized one. The upcoming version of Windows 8 that will run on ARM cores. Otherwise known as WinRT or Metro or the ".NET for Metro style apps" API, depending on what tools you use. WinRT severely cuts down on the traditional Windows API, its System.Windows.Threading namespace is pretty empty.

This is going to generated a ton of questions on SO, the "Eeek, now what do I do" kind. The possible workaround here is to burn up a dummy System.Threading.ManualResetEvent object. It has a WaitOne(TimeSpan) method.

Fwiw, I'm personally not looking forward to programming against this library. By far the most alarming tidbit is in the Q&A section of the link you provided:

Q: I wanted to ask what's up with the Compile method of the System.Linq.Expressions.Expression class.
A: It's not supported on Windows Phone/Xbox, so it only shows up when you target Silverlight + .NET.

Ouch. Portable, sportable. This needs to stew for a while. My sympathies to DevDiv in general and David Kean in particular, tough job.