Let's look now at the changes to our ACE_Message_Block derivative and the new ACE_Data_Block derivative.

The important thing to remember is that the data block (not the message block) is reference counted. When you instantiate a new ACE_Message_Block, it will create one or more ACE_Data_Block objects to contain the data you need. Optionally, you can provide it with a pointer to a data block.

When you finish with a message block, you should use the release() method to make it go away. Do not ever delete an instance of a message block! When you invoke release(), the message block will invoke release() on the data block(s) it contains. If the block's reference count goes to zero as a result then the block will delete itself.

To increment the reference count of a data block, use the duplicate() method of the message block (or blocks) to get a new message block referencing the same data block. This is very efficient since the actual data is not copied.

// $Id$

#ifndef BLOCK_H
#define BLOCK_H

#include "ace/Message_Block.h"

#if !defined (ACE_LACKS_PRAGMA_ONCE)
# pragma once
#endif /* ACE_LACKS_PRAGMA_ONCE */

#include "ace/Synch.h"
#include "mld.h"
#include "work.h"

/*
   In this Tutorial, we derive from ACE_Data_Block for our special data.  With
   the possiblilty that our Task object may forward the unit of work on to
   another thread pool, we have to make sure that the data object doesn't go
   out of scope unexpectedly.  An ACE_Message_Block will be deleted as soon as
   it's release() method is called but the ACE_Data_Blocks it uses are
   reference counted and only delete when the last reference release()es the
   block.  We use that trait to simplify our object memory management.
 */
class Data_Block : public ACE_Data_Block
{
public:
    typedef ACE_Data_Block inherited;

        // Create a data block with a unit of work to be done
    Data_Block (Unit_Of_Work * _data);

    ~Data_Block (void);

        // Returns the work pointer
    Unit_Of_Work *data (void);

protected:
    Unit_Of_Work * data_;
    MLD;                        // Our memory leak detector

        // The ACE_Data_Block allows us to choose a locking strategy
        // for making the reference counting thread-safe.  The
        // ACE_Lock_Adaptor<> template adapts the interface of a
        // number of lock objects so that the ACE_Message_Block will
        // have an interface it can use.
    class Lock : public ACE_Lock_Adapter < ACE_Mutex >
    {
    public:
        typedef ACE_Lock_Adapter < ACE_Mutex > inherited;

        Lock (void);
        ~Lock (void);

            // destroy() will be called to explicitly delete the
            // lock when we no longer need it.  The method will then
            // cleanup to prevent any memory leaks.
        int destroy (void);

    protected:
        MLD;
    };
};

/*
   This simple derivative of ACE_Message_Block will construct our Data_Block
   object to contain a unit of work.
 */
class Message_Block : public ACE_Message_Block
{
public:
    typedef ACE_Message_Block inherited;

    Message_Block (void);
    Message_Block (Unit_Of_Work * _data);

    ~Message_Block (void);

protected:
    MLD;
};

#endif

One of the most difficult parts of this to get right was the Lock object. I didn't even have it in the beginning but I soon realized that the reference counts were getting weird. A little careful reading of the comments and the source informed me that some sort of locking is necessary to keep the counter sane. The simplest thing at that point was to use the ACE_Lock_Adaptor<> to adapt ACE_Mutex appropriately. The next trick was to ensure that the lock object was destroyed at the proper time to prevent both memory leaks and core dumps. The finaly product may be a little bit intimidating at first but it's really quite simple once you understand the motivation.