RE: SDL-News: non-blocking external DB access from within a process


Subject: RE: SDL-News: non-blocking external DB access from within a process
From: Flįvio J. Moritz Jr. (flavio.moritz#digitro.com.br)
Date: Mon Aug 16 1999 - 12:07:14 GMT


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 -----

Worderful idea. Much better than a timer or inserting now/view/import into
the enabling condition.
But, how can I send this wake-up event from the DB-query thread to the SDL
environment on the main thread ?
Exactly how would you implement this event?
Any thoughts ?
Just to remember, people at Telelogic said SDL-Output() is not thread-safe!

[]'s Flavio

> -----Original Message-----
> From: Yoni Rabinovich [mailto:YRABINOV#teledata.co.il]
> Sent: Sunday, August 15, 1999 3:46 AM
> To: 'Fl?vio J. Moritz Jr.'
> Cc: 'sdlnews#sdl-forum.org'
> Subject: RE: SDL-news: non-blocking external DB access from within a
> process
>
>
> This sounds workable, and we did something similar (using enabling
> conditions to essentially wait for the completion of an
> "external" event).
>
> As you correctly point out, this makes you very dependent on
> the precise
> implementation of enabling conditions / continuous signals in SDT.
>
> One small optimization: Maybe instead of setting an SDL timer
> to force the
> transition and checking of the enabling condition, you could send a
> "wake-up" event to the SDL environment from your
> "database-query" thread,
> just before it completes. This "wake-up" event would be
> simple to implement,
> since it wouldn't need to carry any data, nor would it cause
> a signal to be
> injected into the SDL system (via a call to SDL_Output in
> xInEnv). Its sole
> purpose would be to force an iteration of the SDT main loop
> (and hence,
> cause the enabling condition to be checked) exactly when the
> updated data
> from the database is available (as opposed to the timer
> scheme you proposed,
> which may introduce either delay, unnecessary transitions, or both).
>
> 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: 13 August 1999 16:32
> > To: Lista SDL (E-mail)
> > Subject: SDL-news: non-blocking external DB access from within a
> > process
> >
> > 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 -----
> >
> > Still on this "attempt to do non-blocking database access" thing.
> > How about, on a task, in a SDL process, inserting C-code to
> create another
> > thread of execution, responsible for an external database
> query, which
> > upon
> > completion (of the thread and query, of course) changes the
> value of a SDL
> > process variable, which in turn is part of a SDL enabling
> condition ?
> > As a result, the SDL process in question is going to stay in a state
> > waiting
> > for the enabling condition, while the rest of the SDL
> system will go on
> > and
> > the thread will consult the database and change the
> enabling condition.
> > It seems to work! But Telelogic implements enabling
> condition in two ways:
> > - If it as now, import or view, it'll check the enabling
> condition very
> > often. A major overhead then.
> > - If it doesn't contain one of the above, it'll check the enabling
> > condition
> > on every transition.
> > So, to avoid overhead, it'll be necessary to set a timer on
> that process
> > to
> > force a transition and checking of the enabling condition.
> > What you people think about this ?
> > Could you follow my thoughts ?
> > Any flaws on it ?
> >
> > []'s Flavio.
> >
> > > -----Original Message-----
> > > From: Flįvio J. Moritz Jr. [mailto:flavio.moritz#digitro.com.br]
> > > Sent: Friday, August 13, 1999 9:46 AM
> > > To: 'sdlnews#sdl-forum.org'
> > > Subject: RE: SDL-news: On implementations
> > >
> > >
> > > 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 "=?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



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