[ECOS] Variable size Message boxes

[ECOS] Variable size Message boxes

[Rajendran, Balakumaran (CTS)]

Hi,

I need to create message boxes of variable sizes for my application.  In
ECOS, the size of the message box can be configured by the
CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE parameter.  But all the message boxes
created will be of the same size.  Is there a way by which variable size
message boxes can be created and used?

Thanks & Regards,
R.Balakumaran

This e-mail and any files transmitted with it are for the sole use 
of the intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. Any unauthorised review, use, disclosure, 
dissemination, forwarding, printing or copying of this email or any action taken in 
reliance on this e-mail is strictly prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

Re: [ECOS] Variable size Message boxes

[Bart Veer]

>>>>> "Rajendran," == Rajendran, Balakumaran (CTS) <RBalakum@chn.cts-corp.com> writes:

    Rajendran> I need to create message boxes of variable sizes for my
    Rajendran> application. In ECOS, the size of the message box can
    Rajendran> be configured by the
    Rajendran> CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE parameter. But all
    Rajendran> the message boxes created will be of the same size. Is
    Rajendran> there a way by which variable size message boxes can be
    Rajendran> created and used?

Not with the message boxes provided by the kernel.

It is not clear whether you want message boxes which can change size
dynamically, or if you want message boxes of different but fixed sizes.

The former would require some form of dynamic memory allocation, i.e.
if you post to a full message box then the kernel would need to extend
the message box. This would add a lot of overhead to the message box
code, and would add a new dependency on dynamic memory allocation
support for some applications which previously had no such
requirement. It would make it impossible to post to a message box from
inside a DSR since the post operation might now have to block in the
malloc code. It would also introduce a new failure condition. If you
do need this functionality then it can be implemented at the
application level, probably using a condition variable.

The latter is also not currently supported and would have to be
implemented. There would be initialization problems, the basic mbox
data structure would have to be separate from the queue, and there
would be some performance penalties. For most applications a
fixed-size queue is sufficient.

    Rajendran> This e-mail and any files transmitted with it are for
    Rajendran> the sole use
    <snip>

Please do not use bogus signatures like this when posting to public
mailing lists like ecos-discuss. They are meaningless and a waste of
bandwidth.

Bart Veer // eCos net maintainer

Re: [ECOS] Variable size Message boxes

[Jonathan Larmour]

Bart Veer wrote:
> 
> >>>>> "Rajendran," == Rajendran, Balakumaran (CTS) <RBalakum@chn.cts-corp.com> writes:
> 
>     Rajendran> I need to create message boxes of variable sizes for my
>     Rajendran> application. In ECOS, the size of the message box can
>     Rajendran> be configured by the
>     Rajendran> CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE parameter. But all
>     Rajendran> the message boxes created will be of the same size. Is
>     Rajendran> there a way by which variable size message boxes can be
>     Rajendran> created and used?
> 
> Not with the message boxes provided by the kernel.
> 
> It is not clear whether you want message boxes which can change size
> dynamically, or if you want message boxes of different but fixed sizes.

It the latter you can use POSIX message queues from <mqueue.h> from the
EL/IX code in CVS. Or even use the Cyg_MQueue type which is part of the
kernel, in <cyg/kernel/mqueue.hxx>, but which is not part of the *exported*
API because it is solely present to support POSIX message queues. This
means C++ for a start, and the documentation for that API is whatever is in
mqueue.hxx :-). It's a private internal API.
 
> The former would require some form of dynamic memory allocation, i.e.
> if you post to a full message box then the kernel would need to extend
> the message box.

There's a simpler way to do it. Just make the kernel message boxes take
void *'s, and then it is up to the *application* to malloc stuff, and then
when it is received, free it. That is the intended use of the kernel
message boxes to make the implementation simplest and fastest.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Variable size Message boxes

[Bart Veer]

>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:

    <snip>

    >> The former would require some form of dynamic memory
    >> allocation, i.e. if you post to a full message box then the
    >> kernel would need to extend the message box.

    Jifl> There's a simpler way to do it. Just make the kernel message
    Jifl> boxes take void *'s, and then it is up to the *application*
    Jifl> to malloc stuff, and then when it is received, free it. That
    Jifl> is the intended use of the kernel message boxes to make the
    Jifl> implementation simplest and fastest.

That is fine for the messages themselves, and cyg_mbox_put() etc.
already take void* arguments to support this. It is not always
sufficient. The presence of a message in a message box acts as an
event count as well as a data transfer, and typically you will
need to preserve the event count semantics. Manipulating messages
that have already been posted with malloc() and free() will not do
this. 

The current message box implementation requires an array to hold
messages that have been posted but not retrieved. It is that array
which would become variable-sized, i.e. which might need dynamic
memory allocation when posting. Less efficient, there are more things
that could go wrong, and not supported at this time.

Alternatively it would be possible to pass this array and its size as
arguments to the initialization routine. Then the post code would have
to check against a per-mbox maximum queue size rather than a constant
to determine whether or not the operation should block. You might even
want to add a control operation that lets you change the array at
run-time.

Or you can define a message box that works in terms of a linked list
and force application code to supply the requisite list nodes as part
of the message. Again there is no support for message boxes that work
along those lines.

Bart