Threads are normal C-functions started when calling the C-runtime library functions _beginthread or _beginthreadex either explicitly or implicitly (like in MFC) with the thread functions as an argument. The _beginthread also takes a void* as argument. The begin-methods creates a new stack and starts the method by calling it with the void* as argument. As in the nature of void pointers the void* can point to anything. This void* is used for arguments to the thread function. The thread function then have to unpack the data from the void* by typecasting it to something well known. The function is running in its own thread until it returns.

struct rec{
	double d;
	char ch;
}

void f(void * r)
{
	rec *tmp = (rec*) r;
	loop ..
}

rec r;  r.d = 3.1415; r.ch = 2;
_beginthread(f, 0, (void*)&r);
loop too 

The communication between the Active Object (worker thread) and the main thread has to be threadsafe. The communication will be done through a STL queue of bytes. The methods must be thread safe so we dont get any simultaneous reading and writing. This can easily be done by specializing the STL adapter class queue by using a critical section, which is the most simple and fastest synchronization object on Win32 to protect the reading and writing inside the same process:

template 
class ts_queue: public queue
{
	typedef ThreadModel _ThreadModel;
	typedef _ThreadModel::AutoCriticalSection _CritSec;
public:
	ts_queue(){};
	void put(const T in);
	T get();
	bool empty();
protected:
	void Lock() {m_critsec.Lock();}
	void Unlock() {m_critsec.Unlock();}
private:
	_CritSec m_critsec;
};

template 
bool ts_queue::empty()
{
	bool tmp;
	Lock();
	tmp = queue::empty();
	Unlock();
	return tmp;
}


template 
void ts_queue::put(const T in)
{
	Lock();
	push(in);
	Unlock();
}

template 
T ts_queue::get()
{
	T tmp;
	Lock();
	tmp = front();
	pop();
	Unlock();
	return tmp;
}

The ActiveX control creates the thread safe queue and hands a reference to the Active Object through its constructor so they share this instance for communication. The Active Object will implement the Command method like:

void CTransmitThread::Command(void)
{
	if (!m_rqueue.empty())
	{
		unsigned char ch;
		ch = m_rqueue.get();
		m_pComPort->Transmit(ch);
	}
}

The pointer to the comport-object is initialized in the constructor for the thread, but this might as well have been in the PreCommand method. I will not go into detail about the comport object except it opens a com-port for serial communication at 2400 Baud and it implements a method called ComPort::Transmit that will write a byte to the com-port. We will investigate the com-port object later on when talking about the Active Receiver Object.

Adding a Method to the ActiveX Control

The ATL Method Wizard is used for adding a method TransmitByte to the control. In IDL it looks like:

[id(1), helpstring("method TransmitByte")] HRESULT TransmitByte([in] unsigned char ch);

TransmitByte takes a single character as argument and send it to the com-port via the worker thread. Having one method that takes only one simple argument is COM in one of its most simple forms (Automation). The implementation of TransmitByte looks like:

STDMETHODIMP CTransmit::TransmitByte(unsigned char ch)
{
	// TODO: Add your implementation code here
	m_tsqueue.put(ch);
	return S_OK;
}

	CComm():
		m_tt(m_tsqueue)
	{
		m_bWindowOnly = TRUE; 
	}

HRESULT CComm::FinalConstruct( )
{
	BOOL runmode = FALSE;
	HRESULT hres = GetAmbientUserMode(runmode);
	if (!SUCCEEDED(hres))
		runmode = TRUE
	if (runmode)
	{
		m_tt.StartThread();
	}
	return S_OK;
}

void CComm::FinalRelease( )
{
	BOOL runmode = FALSE;
	HRESULT hres = GetAmbientUserMode(runmode);
	if (!SUCCEEDED(hres))
		runmode = TRUE
	if (runmode)
	{
		m_tt-> TerminateThread(); // this method will wait for the worker thread to terminate
	}
}

The two final-methods use the method GetAmbientUserMode to determine whether or not the ActiveX control is in design mode or run mode. Design mode is when you are designing your GUI using VB. VB (like many other containers) loads and instansiates the control also in design mode. It would be stupid to start the threads in design mode so we try to avoid this, but as many other MS stuff this doesnt work. The moral is: do not rely on GetAmbientUserMode to determine the state of the container. Use some other technique to do that. This will be investigated at the end.

Behavior and Termination

At this point we can create a VB program that uses the control. It should have one Edit box where the property MultiLine is set to TRUE and it should hold one instance of the ActiveX Control (You will have to browse for the DLL).

At design time the form could look like:

The code for the VB program would look like:

Private Sub Text1_KeyPress(KeyAscii As Integer)
   Comm1.TransmitByte (KeyAscii)
End Sub

At runtime the VB program would look like:

As you can see the control is invisible at runtime. This is a registry setting that can be manipulated through the MiscStatus entry in the reg-script. Finding the right bits to set is not a simple task and this is an effort in itself. When changes are made to the MiscStatus you have to recompile your VB program to make the changes shine through. The problem about the current implementation of the ActiveX control is that the Active Transmitter Object waits actively on input from container (VB program), meaning it loops and for each iteration it checks some halt condition. This active waiting will slow down execution of the VB program (and actually the whole desktop). It will feel like rubber bands are attached to all windows. The active waiting happens in the virtual Command method. In the following I will solve the problem in two tempi. First I will do the obvious one using Win32 events on behalf of loosing the ability to control the termination of the Active Object. In the second step I will state the Design Pattern/ strategy for termination of Active Objects by introducing Terminators

Adding Support for Win32 Events

The rubber band problem can easily be solved using theWin32 synchronization mechanism: Events. The reader on the thread safe queue will wait passively for someone to put data in the queue using the Win32 ::WaitForSingleObject. The event that something has arrived will be signaled from the put method on the thread safe queue, like:

template 
class ts_queue: public queue
{
	typedef ThreadModel _ThreadModel;
	typedef _ThreadModel::AutoCriticalSection _CritSec;
public:
	ts_queue():m_event(false, true){}; //manually reset
	void put(const T in);
	T get();
	bool empty();
	bool waitNonEmpty();
	void Lock() {m_critsec.Lock();}
	void Unlock() {m_critsec.Unlock();}
private:
	_CritSec m_critsec;
	CEvent m_event;
};



template 
bool ts_queue::waitNonEmpty()
{
	Lock();
	if (!empty())
	{
		Unlock();
		return true;
	}
	m_event.ResetEvent();
	Unlock();
	::WaitForSingleObject(m_event, INFINITE);
	return true;
}


template 
void ts_queue::put(const T in)
{
	Lock();
	push(in);
	m_event.SetEvent();
	Unlock();
}

The Active Transmitter Object will have to call waitNonEmpty() instead of calling the empty() method actively. This method will execute (passively) until a character is put into the queue. The method Command() now looks like:

void CTransmitThread::Command(void)
{
	if (m_rqueue.waitNonEmpty() && (MayIContinue()))
	{
		m_pComPort->Transmit(m_rqueue.get());
	}
}

The CEvent class used in the threadsafe queue is not a part of ATL but snapped and modified from the MFC library. It simply encapsulates the Win32 event mechanism into a class (see the source).

class CEvent : public CSyncObject
{

// Constructor
public:
	CEvent(BOOL bInitiallyOwn = FALSE, BOOL bManualReset = FALSE,
		LPCTSTR lpszNAme = NULL, LPSECURITY_ATTRIBUTES lpsaAttribute = NULL);

// Operations
public:
	BOOL SetEvent();
	BOOL PulseEvent();
	BOOL ResetEvent();
	BOOL Unlock();

// Implementation
public:
	virtual ~CEvent();
};

Using the CEvent and calling WaitForSingleObject will make termination of the thread awkward. Termination can only happen right after a character has been sent to the Active Transmitter Object. This is not a good strategy for termination. In the following I will introduce a strategy for termination that is widely applicable.

The following has nothing to do with Arnold Schwartzenegger and it is not science fiction. It is based on a true story but there might be a sequal. The idea of the Terminator is that each time an active object has to wait for some kind of Win32 object using a ::WaitForSingleObject it will use the terminator instead. The Active Objects will at startup time sign up as an observer for the termination event. When the ActiveX control is terminating it will ask the terminator to set the terminate event and all Active Objects that is passively waiting for an event to happen will at this time be interrupted and can then terminate in an ordered manner. Instead of calling ::WaitForSingleObject the Active Objects will call Terminator::Wait with the event as argument. The Wait() method will then call ::WaitForMultipleObjects instead of ::WaitForSingleObject with both the event from the Active Object and the terminate event as argument. The Terminator class looks like:

class Terminator
{
private:
	CEvent m_termEvent;
	bool is_terminating;
	typedef CComMultiThreadModel ThreadModel; 
	typedef ThreadModel _ThreadModel;
	typedef _ThreadModel::AutoCriticalSection _CritSec;

	_CritSec m_signUpCS; 
 	vector m_runningThreads; // protected by m_signUpCS
public:
	void TerminateAll();
	bool TerminatingAll();
	bool Wait(CSyncObject * pSyncObj); // True if pSync is now Locked
									   // False Means terminated or timed out
	bool Wait(HANDLE eventHandle); // True if pSync is now Locked
	void SignUp(HANDLE hThread);
public: // singleton
	static Terminator* Instance();
	LONG Release();
	static LONG m_cRef;
protected:// Singleton
	Terminator();
	~Terminator();
private: // Singleton
	static Terminator* m_instance;

};

The implementation of the Terminator::Wait() method looks like:

bool Terminator::Wait(HANDLE eventHandle)
{
	HANDLE h[2];
	h[0] = eventHandle;
	h[1] = m_termEvent.m_hObject;
	DWORD lockVal;
	lockVal = ::WaitForMultipleObjects(2, h, false, INFINITE);
	return lockVal == WAIT_OBJECT_0;
}

And the Terminator::TerminateAll that is used by the control to terminate the control looks like:

void Terminator::TerminateAll()
{
	is_terminating = true;
	m_termEvent.SetEvent();

	vector::iterator i;
	for (i=m_runningThreads.begin(); i

template 
bool ts_queue::waitNonEmpty()
{
	Lock();
	if (!empty())
	{
		Unlock();
		return true;
	}
	m_event.ResetEvent();
	Unlock();
	Terminator * m_pTerm = Terminator::Instance();
	bool tmp = m_pTerm->Wait(&m_event);
	m_pTerm->Release();
	m_event.ResetEvent();
	return tmp;
}