RE: SDL-News: On implementations


Subject: RE: SDL-News: On implementations
From: Yoni Rabinovich (YRABINOV#teledata.co.il)
Date: Tue Aug 17 1999 - 06:40:46 GMT


The originator of this message is responsible for its content.
-----From Yoni Rabinovich <YRABINOV#teledata.co.il> to sdlnews -----

I'm surprised to hear that the SDT kernel doesn't support multi-threading in
Unix / NT processes.

I'm almost sure that in the RTOS world, they support mapping SDL processe
instances to RTOS (e.g. pSOS, VxWorks etc.) "tasks". RTOS multi-tasking
typically resembles Unix multi-threading (at least, to a greater respect
than it resembles Unix multi-processing). So, I would have thought that the
SDT kernel would support Unix multi-threading, but I may well be wrong.

Note that ObjecTime / Rational Rose Realtime **does** support
multi-threading (although that tool is based on ROOM, not SDL, so I'm not
sure it belongs in this forum...). In fact, I recently implemented something
similar to what you're trying to do using that tool (with NT
multi-threading).

> -----Original Message-----
> From: flavio.moritz#digitro.com.br [SMTP:flavio.moritz#digitro.com.br]
> Sent: 16 August 1999 14:30
> To: Lista SDL (E-mail)
> Subject: RE: SDL-news: On implementations
>
> The originator of this message is responsible for its content.
> -----From "=?x-user-defined?Q?Fl=E1vio_J._Moritz_Jr.?="
> <flavio.moritz#digitro.com.br> to sdlnews -----
>
> > Hmmm, what about defining an SDL process which handles the
> > interaction with
> > the database, and runs in its own thread ? This process would
> > receive an SDL
> > signal from another SDL process, whenever the database needs
> > to be queried.
> > It would then make the call to the database API in an SDL task. Upon
> > returning from the database API, it would send back an SDL
> > signal with the
> > data retrieved from the database (with OUTPUT TO Sender).
>
> That would be my dream comming true, but I'm not sure if SDT can generate
> code in order to get SDL processes implemented as threads.
> Vibhor Agarwal said Object Geode can and has a POSIX run time library
> suited
> for that. Wonderful, isn't it?
> I know SDT can generate code in a way that a SDL process gets implemented
> as
> a separate O.S. process.
> The said part of it is that I still would have to write down an
> environment,
> with interprocess communication code, in order to get this SDL process,
> now
> a OS process, to talk to another SDL process. That would be the same as
> writing an interface middleware from scratch.
>
> > Are you saying that this SDL process won't be able to send
> > SDL signals to
> > other SDL processes in different threads via SDL_Output in a
> > thread-safe
> > manner ?
>
> Well, I assumed that from the following email I got from Telelogic's
> personnel:
>
> -------------------------------------------------------------------------b
> eg
> in quote---
> Dear Flavio,
> Regarding the question (below) concerning; thready safety.
> I have received this answer from one of our experts.
> No, it is not possible to use xGetSignal and SDL_Output in the way that
> you want to. However, there is another way to do this.
> The solution is to implement a message sending/receiving protocol
> between your database thread and the SDLthread. The protocol should use
> XInEnv and XOutEnv to send/receive signals to the SDL system.
> This is the general way to deal with database queries from SDL.
> Cheers
> Tommy Bergstrom
> Telelogic Support
>
> > From: Flávio J. Moritz Jr.[SMTP:flavio.moritz#digitro.com.br]
> > Sent: den 10 augusti 1999 15:46
> > Subject: thread safety (ID:10266)
> >
> > Hi,
> > I was wondering, how thread-safe is the generated C-code by SDT ?
> > We're currently using TAU3.4, if that matters.
> > Why am I asking this ?
> > Because I want to start a thread to do some tasks and upon completion,
> > use xGetSignal and SDL_Output to send a signal to some SDL process.
> > Why would I want to do that ?
> > In order to make a (SQL) database query from a TAU generated
> > application without blocking this application in a database function
> call.
> > How about it ?
> > Is it possible ?
> > How does everybody else deals with database queries from SDL ?
> >
> > []'s Flávio
> -------------------------------------------------------------------------e
> nd
> quote---
>
>
> []'s Flavio
>
>
> > -----Original Message-----
> > From: Yoni Rabinovich [mailto:YRABINOV#teledata.co.il]
> > Sent: Sunday, August 15, 1999 3:33 AM
> > To: 'Fl?vio J. Moritz Jr.'; sdlnews#sdl-forum.org
> > Subject: RE: SDL-news: On implementations
> >
> >
> > Hmmm, what about defining an SDL process which handles the
> > interaction with
> > the database, and runs in its own thread ? This process would
> > receive an SDL
> > signal from another SDL process, whenever the database needs
> > to be queried.
> > It would then make the call to the database API in an SDL task. Upon
> > returning from the database API, it would send back an SDL
> > signal with the
> > data retrieved from the database (with OUTPUT TO Sender).
> >
> > Are you saying that this SDL process won't be able to send
> > SDL signals to
> > other SDL processes in different threads via SDL_Output in a
> > thread-safe
> > manner ?
> >
> > One other point: note that you can use the ##EXTSIG macro to
> > optimize outputs
> > to the environment (enabling you to simply make a direct
> > function call to
> > your "environment" function, rather than calling SDL_Output
> > to send a signal
> > to the environment pseudo-process). You'll need to tweak the
> > code a little
> > if you want EXTSIG outputs to be traced, though (but this is
> > easy to do).
> >
> > > -----Original Message-----
> > > From: flavio.moritz#digitro.com.br
> > [SMTP:flavio.moritz#digitro.com.br]
> > > Sent: 13 August 1999 14:46
> > > To: sdlnews#sdl-forum.org
> > > Subject: RE: SDL-news: On implementations
> > >
> > > The originator of this message is responsible for its content.
> > > -----From "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > >
> > > Sure, Yoni.
> > > We do exactly the same thing here.
> > > But, lets get back to the database access problem.
> > > Let's say the SDL application wants to make a query on a
> > table stored in a
> > > MySQL, PostgreSQL or even Oracle database server.
> > > I can't see how I can use the environment functions to make
> > this query
> > > without blocking the whole SDL system.
> > > Because this query will actually be a function call. The
> > application will
> > > return from this function call only after completion of the query.
> > > So, things would work this way:
> > > - The SDL process wants to make a query on a DB server,
> > thus sending a
> > > signal to the environment;
> > > - xOutEnv is called by the SDT main loop to handle this signal;
> > > - In xOutEnv, a function from the database client API is
> > called to handle
> > > the query;
> > > - Query takes a lot of time, meanwhile the SDL system is
> > freezed on a DB
> > > client API function call.
> > > So I was wondering if I could put this DB function call on
> > a separate
> > > thread
> > > and use SDL_Output to send a signal from this thread to the original
> > > thread
> > > informing query completion.
> > > But people at Telelogic told me that SDL_Output is not
> > thread-safe. They
> > > said:
> > > -- quote ---
> > > "The solution is to implement a message sending/receiving
> > protocol between
> > > your database thread and the SDLthread. The protocol should
> > use XInEnv and
> > > XOutEnv to send/receive signals to the SDL system."
> > > -- end quote ---
> > > Well, that's exactly how we do it now and I tell you, it's
> > really boring
> > > to
> > > write this "middleware".
> > > Unfortunately, I see no exit signal here. Thats the way it
> > has to be done.
> > > Oh, it just occured to me that a thread for you could be
> > different from a
> > > thread for me.
> > > I'm talking about POSIX threads on UNIX OS processes.
> > > A child thread shares most of the data from its parent
> > thread, while a
> > > child
> > > process doesn't.
> > >
> > > Well, anyway, it's wonderful to see that I finally found a place to
> > > discuss
> > > this kind of things.
> > > Thanks.
> > >
> > > []'s Flavio
> > >
> > > > -----Original Message-----
> > > > From: owner-sdlnews#sdl-forum.org
> > > > [mailto:owner-sdlnews#sdl-forum.org]On
> > > > Behalf Of Yoni Rabinovich
> > > > Sent: Friday, August 13, 1999 5:49 AM
> > > > To: 'Fl?vio J. Moritz Jr.'; sdlnews#sdl-forum.org
> > > > Subject: RE: SDL-news: On implementations
> > > >
> > > >
> > > > The originator of this message is responsible for its content.
> > > > -----From Yoni Rabinovich <YRABINOV#teledata.co.il> to
> > sdlnews -----
> > > >
> > > > Hi Flavio,
> > > >
> > > > I developed a fairly large telecom application a few
> > years ago with
> > > > Telelogic's SDT (the SDL core of TAU).
> > > > The way we handled issues like those you raise were by using the
> > > > "environment" functions (xInEnv, xOutEnv etc.)
> > > >
> > > > The xInEnv function is called as part of the main loop
> > of the SDT
> > > > scheduler. Our SDT application ran on top of the pSOS Real
> > > > Time OS, as a
> > > > pSOS task (thread). External applications generated pSOS
> > > > events when they
> > > > wanted to pass data to the SDL system. The SDT main loop
> > > > would check for
> > > > such events in xInEnv, and translate them into SDL signals
> > > > sent into the
> > > > system. We designed it such that the SDL system would not
> > > > block waiting for
> > > > inputs from the external applications, so as not to block the
> > > > SDL system
> > > > itself. On the other hand, the SDT task would "go to sleep"
> > > > if there was
> > > > nothing for it to do (i.e. no internal SDL signals or timers
> > > > or external
> > > > events pending).
> > > >
> > > > Regards,
> > > >
> > > > Yoni Rabinovitch
> > > > R&D Team Leader
> > > > ADC Teledata Communications
> > > > 7 Ha'sadnaot St, Hertzlia, 46120, Israel
> > > > email: yrabinov#teledata.co.il
> > > > Phone: +972-9-9591741
> > > > Fax : +972-9-9591444
> > > >
> > > > > -----Original Message-----
> > > > > From: flavio.moritz#digitro.com.br
> > > > [SMTP:flavio.moritz#digitro.com.br]
> > > > > Sent: 12 August 1999 22:14
> > > > > To: sdlnews#sdl-forum.org
> > > > > Subject: SDL-news: On implementations
> > > > >
> > > > > The originator of this message is responsible for its content.
> > > > > -----From "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've been lurking on this list for a while now and
> > haven't seen any
> > > > > discussion on SDL tools.
> > > > > Well, I not actually interested in talking about the tool
> > > > itself, but
> > > > > rather
> > > > > how people use these tools.
> > > > > Let me give you an example.
> > > > > I use Telelogic's tools (TAU) to design telecom applications.
> > > > > It's (Telelogic's) C code generator implements the application.
> > > > > Those applications are compiled and run on UNIX boxes.
> > > > > Whenever I need to access a database server, I use interprocess
> > > > > communications protocols to send messages to another UNIX
> > > > process which in
> > > > > turn uses the database API.
> > > > > Just because I don't want my "SDL" app to block on a
> > > > function call while
> > > > > waiting for the database server.
> > > > > So, I was wondering. How does anybody else do the same thing ?
> > > > > How about shrinking this "middleware" into a thread ?
> > > > > Wouldn't it be better ?
> > > > > Can you see the kind of conversations I would like to have ?
> > > > > Is this an appropriate forum for this ?
> > > > > Can I start this kind of discussions here?
> > > > > Does anybody knows a better forum for this?
> > > > > Any mailing lists or newsgroups ?
> > > > >
> > > > > Please, don't take me wrong. I find people here very
> > > > helpful. I just don't
> > > > > want to bother you with things that aren't of your interest.
> > > > >
> > > > > []'s Fl?vio Moritz
> > > > >
> > > > > "The chase is better than the catch."
> > > > >
> > > > >
> > > > > -----End text from "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > > > > Join http://www.sdl-forum.org/Society/members.htm for extra
> > > > SDL Forum
> > > > > Society benefits
> > > > > For help, email "majordomo#sdl-forum.org" with the body of
> > > > your email as:
> > > > > help
> > > > > or (iff this does not answer your question) email:
> > > > > owner-sdlnews#sdl-forum.org
> > > >
> > > > -----End text from Yoni Rabinovich <YRABINOV#teledata.co.il>
> > > > to sdlnews -----
> > > > Join http://www.sdl-forum.org/Society/members.htm for extra
> > > > SDL Forum Society benefits
> > > > For help, email "majordomo#sdl-forum.org" with the body of
> > > > your email as:
> > > > help
> > > > or (iff this does not answer your question) email:
> > > > owner-sdlnews#sdl-forum.org
> > > >
> > >
> > >
> > > -----End text from "=?iso-8859-1?Q?Fl=E1vio_J._Moritz_Jr.?="
> > > <flavio.moritz#digitro.com.br> to sdlnews -----
> > > Join http://www.sdl-forum.org/Society/members.htm for extra
> > SDL Forum
> > > Society benefits
> > > For help, email "majordomo#sdl-forum.org" with the body of
> > your email as:
> > > help
> > > or (iff this does not answer your question) email:
> > > owner-sdlnews#sdl-forum.org
> >
>
>
> -----End text from "=?x-user-defined?Q?Fl=E1vio_J._Moritz_Jr.?="
> <flavio.moritz#digitro.com.br> to sdlnews -----
> Join http://www.sdl-forum.org/Society/members.htm for extra SDL Forum
> Society benefits
> For help, email "majordomo#sdl-forum.org" with the body of your email as:
> help
> or (iff this does not answer your question) email:
> owner-sdlnews#sdl-forum.org

-----End text from Yoni Rabinovich <YRABINOV#teledata.co.il> to sdlnews -----
Join http://www.sdl-forum.org/Society/members.htm for extra SDL Forum Society benefits
For help, email "majordomo#sdl-forum.org" with the body of your email as:
    help
or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:41 GMT