Something like this (C#) MIGHT do the trick...
public class MyNonThreadSafeClass()
{
public MyNonThreadSafeClass()
{
currentThreadId = Thread.CurrentThread.ManagedThreadId;
}
private readonly int currentThreadId;
public void SomeNonThreadSafeMethod()
{
AssertSameThread();
//do your thing
}
private void AssertSameThread()
{
if(currentThreadId != Thread.CurrentThread.ManagedThreadId)
throw new InvalidOperationException("Method must be called on the same thread that created the containing object");
}
}
This would ensure that only the thread that created the object instance could work with it. Variations of this could ensure that no one method is called concurrently by different threads at the same time (but allow one thread to create the instance and then give it to another thread to work with), or that the creating thread must have a message pump (and is thus a UI thread and so very likely to be the app's "main" thread).
However, overall, if you expect your library to be used by parallel threads of a process, and want to support that, I would make it thread-safe. It's not really that hard; use monitors, mutexes or other locks to protect shared state, and favor "pure functions" that don't rely on instance-scoped state.