Thread

Not multithreaded? (Sdk)

Not multithreaded? // Sdk

1  |  

esumerfd

Sep 10, 1998, 1:28pm
With your design of using the aw_instance_set method it appears as
though your API is not thread safe. Is there a reason for this?

I would imagine that in a high volume world, with lots of bots, each bot
would start reacting slower to stimulus. You could not take advantage of
multi cpu hardware so there would be no hardware rampup available.

I am sure with small greeter bots this will not be a problem but when
you start getting into your conversation bots that apply some AI
technology to make the conversation seem real you are going to see a
long delay in each event function. During this time all other bots are
lifeless, a kind of temporary bot death I guess.

An alternate design would be to pass the instance handle to each
function so that context can be managed appropriately by the API and
each event function gets passed the bots context from which it gets the
relevent bot information.

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

roland vilett

Sep 10, 1998, 7:51pm
Yes that is correct the SDK is not multi-threaded. We evaluated making it
thread-safe and decided that the additional design requirements that would
impose would delay the SDK's release significantly when most developers will
not even need it to be thread-safe.

If demand for a thread-safe SDK is sufficient we'll consider adding that in
a future release. Right now the goal is to get something, ANYTHING, out
there for people to use. :)

-Roland

[View Quote]

thierry nabeth

Sep 11, 1998, 3:50pm
Hello,

I personally considere multithreading very important.

For the reasons mentioned by esumerfd.

In particular, multithreading would be very important if we want
to try to interface the SDK with java.
(which appear to me as a better language for developing bots because
of the multithreading, the garbage collection, etc.).

Note: Encapsulation of the SDK into java shouldn't be too difficult.
Anyone interested by the idea ?


Thierry Nabeth
Research Fellow,
INSEAD CALT (the Centre for Advanced Learning Technologies).
http://www.insead.fr/CALT/

PS:
Any plan to have a java version of the SDK ?


[View Quote] > Yes that is correct the SDK is not multi-threaded. We evaluated making it
> thread-safe and decided that the additional design requirements that would
> impose would delay the SDK's release significantly when most developers will
> not even need it to be thread-safe.
>
> If demand for a thread-safe SDK is sufficient we'll consider adding that in
> a future release. Right now the goal is to get something, ANYTHING, out
> there for people to use. :)
>
> -Roland
>
[View Quote]

esumerfd

Sep 11, 1998, 4:37pm
I like the Java idea but I fear it is a great deal more difficult that you are
assuming.

Certainly we can encapsulate C function calls into Java methods but you will
stumble on the aw_wait function because it is supposed to call your java methods
and it will not be able to.

One thing you might be able to do is use the sdk to write a generic server that
would export the sdk to a socket interface. Then you can write java clients to
drive it.

Each java thread would have to talk to a different generic server to get around
the threading problem. Unless you want to build a single generic server that
serialized all parallel requests to a single aw sdk thread, you know, queued up
the requests and processed them one at a time.

It would be quite a lot of work to correctly model the AW interface but once that
was done it shouldn't take long to implement the client side.

You know, the more I write, the more interesting this sounds. Wait, it will not
work, because the sdk took control of the "select" function in the aw_wait
function we couldn't even trap our own socket events.

It would be really cool to implement a few interfaces to get all the events that
are generated. Instantiate an Avatar class with a login name and priv password to
login. Call its enterWorld method to send it somewhere. Then instantiate a sign
object and call its setText method. Pass the sign object to the avatar so it can
write messages on it. That would require a standard AwTextIF for the Avatar class
to implement. Am I getting carried away yet. OO rocks. Especially Javas' interface
models.

I think I am dreaming too much. Sorry if I wasted your time.

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

[View Quote] > Hello,
>
> I personally considere multithreading very important.
>
> For the reasons mentioned by esumerfd.
>
> In particular, multithreading would be very important if we want
> to try to interface the SDK with java.
> (which appear to me as a better language for developing bots because
> of the multithreading, the garbage collection, etc.).
>
> Note: Encapsulation of the SDK into java shouldn't be too difficult.
> Anyone interested by the idea ?
>
> Thierry Nabeth
> Research Fellow,
> INSEAD CALT (the Centre for Advanced Learning Technologies).
> http://www.insead.fr/CALT/
>
> PS:
> Any plan to have a java version of the SDK ?
>
[View Quote]

roland vilett

Sep 11, 1998, 4:50pm
>In particular, multithreading would be very important if we want
>to try to interface the SDK with java.

But not required. If a Java class were created to encapsualate the current
SDK, the SDK wrapper methods could just be declared as synchronized. If the
SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK
methods return immediately so opportunities for one thread to block others
while in the SDK would be minimal

>(which appear to me as a better language for developing bots because
>of the multithreading, the garbage collection, etc.).


I think the "better" language for bot development is whatever language you
the programmer happen to be comfortable and familiar with.

>Note: Encapsulation of the SDK into java shouldn't be too difficult.
>Anyone interested by the idea ?


A couple of months ago when we first announced work on a C-level API into
Active Words, several people almost immediately offered to implement a Java
wrapper. I don't remember who they were though - are you guys still around,
and if so, are you still interested? :)

-Roland

roland vilett

Sep 11, 1998, 5:01pm
>Certainly we can encapsulate C function calls into Java methods but you
will
>stumble on the aw_wait function because it is supposed to call your java
methods
>and it will not be able to.


Is it not possible at all to have C code call Java routines? Not even in
some kludgey way? Sorry I'm not that familiar with the details of
interfacing Java and C.

If not, it may turn out that a native Java implementation of the SDK is the
only viable long-term solution for Java developers...

>You know, the more I write, the more interesting this sounds. Wait, it will
not
>work, because the sdk took control of the "select" function in the aw_wait
>function we couldn't even trap our own socket events.

Just because aw_wait() calls select() on its sockets doesn't mean that your
code couldn't also call select() on your socket, right? Or am I missing
something. Also, if you call aw_wait (0) it doesn't call select() at all,
it just checks each instance's sockets individually for incoming traffic.
This is to work around some nasty performance problems I've encountered with
the Windows select() call under certain versions of Winsock.

-Roland

esumerfd

Sep 11, 1998, 6:57pm
[View Quote] > will
> methods
>
> Is it not possible at all to have C code call Java routines? Not even in
> some kludgey way? Sorry I'm not that familiar with the details of
> interfacing Java and C.
>
> If not, it may turn out that a native Java implementation of the SDK is the
> only viable long-term solution for Java developers...
>

Your problem is that you are not calling a java method, instead what you really
have to do is call the java interpreter and tell it to go run the appropriate
method. I have never done this so I can say that it is impossible.

I imagine the issues of managing context across multiple calls to a jam are
substantial. It would have to have a way to reenter the same jam multiple times.
Its time to post a question to comp.lang.java.programming.

> not
>
> Just because aw_wait() calls select() on its sockets doesn't mean that your
> code couldn't also call select() on your socket, right? Or am I missing
> something. Also, if you call aw_wait (0) it doesn't call select() at all,
> it just checks each instance's sockets individually for incoming traffic.
> This is to work around some nasty performance problems I've encountered with
> the Windows select() call under certain versions of Winsock.

In a single threaded world you can only have one call to "select" at a time
because it is a blocking call that waits for a list of events. If some boot code
also called select with a different list of events the then it would block there
and you could not receive AU events.

In a perfect request, response world on a single socket you can use two selects
because you know whether you are about to receive a request or a response, but
with multiple sockets and the AU protocol has a number of unsolicited messages
that are sent to the client, it is not going to work. Note that I am making some
assumptions here based on my knowledge of the AU browser protocol. I assume you
haven't re-engineered this too much.

You said you are not calling select. The alternative is read poll the sockets
with a very short, or zero time out. This is very inefficient especially in a
system requiring short response times because the polling interval has to be so
short to guarantee the short response time.

Maybe I am missing something. Do you see continuous of frequent CPU usage from
the boot processes?

In my unix (AIX) background I seem to remember an alternative to select called
"poll". It performed the same functionality but was a great deal more efficient.
I think it was POSIX compliant but I have no clue if this is relevant in a
windows world.

I am still in theory mode here. Its time I found a C compiler and started
implementing the sdk. I imagine the GNU compiler will work wont it?

>
>
>
> -Roland
>

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

esumerfd

Sep 11, 1998, 7:14pm
[View Quote] >
> But not required. If a Java class were created to encapsualate the current
> SDK, the SDK wrapper methods could just be declared as synchronized. If the
> SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK
> methods return immediately so opportunities for one thread to block others
> while in the SDK would be minimal
>

This isn't exactly true because it is the callback functions that must be
synchronied not the aw functions. Your problem is that you are protecting the
time from when a bot calls aw_instance_set and the next time that function is
called. I know you have a global in there, called aw_current_bot of something,
just waiting to be changed by another thread.

It is possible for a bot to trap an event, call aw_instance_set and then spend
lots of time saying things, changing objects, yadda yadda yadda, and no other
thread can get a look in just in case they call aw_instance_set as well.

With this architecture a good bot architect will have to implement a state
machine to track what has been said so that each time an event goes off it can
say the next thing. Though without a user event machanism this isn't going to
work either.

I should have written this in my last reponse but there is a solution to the
"waiting on AW sockets and user sockets" problem and it will allow the creation
of state machine driven bots. You must write an aw_add_event(event, function)
function that a bot can use to pass their own events to your sdk. Then you can
just wait on all of them and call the appropriate function when they are
notified.

>
>
>
> -Roland
>

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

roland vilett

Sep 11, 1998, 8:47pm
>You said you are not calling select. The alternative is read poll the
sockets
>with a very short, or zero time out. This is very inefficient especially in
a
>system requiring short response times because the polling interval has to
be so
>short to guarantee the short response time.


Well I said I'm only not calling select in the case where you call aw_wait()
with a timeout of zero. In this case each read socket is polled once. If
you call aw_wait() with a positive timeout value, it uses select(). The
reason for this is that I've had a problem where the select on some PCs
blocks for 500 milliseconds when the select timeout is specified to be 0
milliseconds. If you pass in a zero timeout select() it is supposed to
return immediately, so as far as I can tell there is a very serious bug out
there in some versions of Winsock.

>In my unix (AIX) background I seem to remember an alternative to select
called
>"poll". It performed the same functionality but was a great deal more
efficient.
>I think it was POSIX compliant but I have no clue if this is relevant in a
>windows world.


I'm not aware of a "poll" equivalent under Windows.

>I am still in theory mode here. Its time I found a C compiler and started
>implementing the sdk. I imagine the GNU compiler will work wont it?


In theory it should, although again so far I've only tested the SDK using
Visual C++. If any problems arise I expect they would be at the link stage,
as came up with Borland, because of the different way the exports in aw.lib
are handled.

-Roland

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2021. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn