Should I use a thread to asynchronously access my device connected to the PCI bus?

Question 1

Are devices connected through PCI guaranteed to deliver data at a certain speed?

No. To my understanding, PCI is a shared bus with bus mastering, a feature that allows a single device to temporarily utilize the full bus bandwidth. In non-server environments, that usually means 133MB/s of bandwidth. Once you have a few I/O cards on the PCI bus, you can see how bandwidth might become scarce under load. Misbehaving devices can also adversely affect latency; some controllers hang until its drive responds to I/O, but granted, that's an abnormal situation.

When communicating with the device, I would like my UI to stay responsive. Is it a good idea to kick off communication with the device in a (threadpool) thread, or is the overhead associated with this too large compared to how fast accessing the PCI bus is?

When writing user-facing software, it always a good idea to separate the UI from I/O or other potentially long-running processes. For example, the modern Android SDK enforces this in its HTTP client - it throws an exception if an HTTP request is executed on the UI thread.

Depending on the version of the .NET framework you are targeting, you have several options for separating the device communications from the UI. Take a look at Parallel Processing and Concurrency in the .NET Framework for a high-level overview of the various options. Threading is low-level abstraction, and you may find it easier and less error-prone to use a higher-level abstraction such as Tasks or C#'s async and await keywords.

Question 2

In general, any time you have the opportunity to write code without thread affinity, it's often a good idea to do so. That way you have the freedom to switch off the UI thread when and if it becomes a responsiveness problem. Designing your API for this I/O using Async methods also keeps your options open going forward in a good way.

Whether the thread you're on is a threadpool thread or one you spawn yourself seems irrelevant if you don't have to occupy it for long periods of time. And if you can do Async I/O then a threadpool thread should be fine.

Question 3

I think using a long running background thread makes sense when you need to monitor the hardware status. TaskCreationOptions.LongRunning looks like a good fit.

Also, using the new async/await feature of C# to interact with the device asynchronously makes sense to me. I am not sure it would help but here is a snippet to illustrate how I usually deal with hardware interaction (for me it's often WinUSB devices):

class Controller : IDisposable // to dispose the unmanaged resources related to the hardware
{
    // this will be used to call back to the UI
    private static readonly SynchronizationContext DefaultContext = new SynchronizationContext();

    public Controller()
    {         
        Task.Factory.StartNew(this.Monitor, ct, TaskCreationOptions.LongRunning);
    }

    public async Task<Result> ActionOnHardwareAsync(object parameter)
    {
        // you may need to synchronize with the monitor method here.  
    }

    // This method monitors hw status, calling back to the UI when something happens
    private void Monitor(object state)
    {
        // Do some stuffs...
        this.synchronizationContext.Post(~ your SendOrPostCallback here ~, ~ event from the hw ~);
    }
}