Re: Tasks and C/C++ code.

[dennison@telepath.com]

In article <72b35b$pll$1@nnrp1.dejanews.com>,
  dbotton@hotmail.com wrote:
> I think it would be practical to create a protected type that wrapped your C
> function to insure that it is not be run concurrently (if it isn't safe). If
> it's safe then just call it as you would any other Ada Procedure/Function.

That will only work under both of the following conditions:

 o There is only *one* object of that protected type in use.

If there are multiple objects of the protected type declared, then there's
nothing stopping two tasks from using different protected objects to call the
same routine simultaniously.

 o The C routine in question does not rely on task-local data for proper
operation or for parameter data.

In Ada we are used to data being either local in *scope*, or visible to all
tasks. But this is not nessecarily true when we leave Ada's happy confines.

eg: The Nighthawk Ada compiler splits tasks into separate Unix processes. All
Ada memory allocations are performed from shared memory sections. However,
their C compiler and OS library routines allocate memory from process space.
That means any data that was dynamicly allocated by a different task within a
C routine or OS library routine is unreadable from any but the calling task.
Thus calling X or Motif routines directly from different tasks will blow up,
regarless of how the calls are synchronized.

Many of the newer threaded OS'es have the concept of "thread-local" data. That
could cause the same problem.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own