1  |   Order by index

Apr 24, 2006, 12:19pm

Just a quick question ... I've been trying to think my way around this, but
I keep coming to the same conclusion and I'd just like to check with those
that may know or have an opinion what their views are.

I've been playing with multi-threading and the SDK in .NET (C#), having
different functions of a single bot operating in their own threads as well
as running multiple bot instances in their own threads (i.e. within the same
process). Object sychronisation between threads is a breeze in .NET, however
I need to make a base framework thread-safe in a way that doesn't require
the applications that are built upon it to care about the threading.
Unfortunately, it strikes me that there's no *simple* way to make the SDK
thread safe in this way.

An example of the problem could be where there are two threads running
within a single bot process, both of which are interacting with the objects
in the world. I can neither predict nor guarantee the function of an
application thread when two separate threads are setting the same SDK
attributes (AW_OBJECT_NUMBER, AW_OBJECT_X, AW_OBJECT_Y, AW_OBJECT_Z, etc.)
and making calls to the SDK. Using the threading and synchronisation
capabilities of .NET, I can ensure that a single thread "owns" the SDK at
any point in time, however this would involve introducing (what I would
consider to be) needless overheads on all calls to the SDK, including the
attribute getter/setter methods and I want the applications themselves
(built on the framework) to be developed the same regardless of threading.

The only way I could see to guarantee the integrity of the thread processes
was to rework the interface the the SDK using an alternative method of
making the calls from code, building a complete "command" that is then
executed through the framework against the SDK methods. This would give me
an opportunity to perform the whole lock/process/unlock within the new
mechanism and each call subsequent call would wait for the lock to be
released. I had hoped to keep to the AW SDK documentation as closely as
possible (to avoid the need to redocument everything as well as keeping a
common frame of reference for developers), and this method doesn't really
achieve that to the extent I intended.

Does anyone have any ideas for alternative approaches? Basically, I don't
want to force a developer to make calls to "grab and release" the SDK
methods around their processes as this is unnecessary complexity, leaves the
door wide open for irritating and hard-to-find bugs as well as stiffling the
extention of objects through polymorphism. I also don't want to be loading
and managing more than one instance of the SDK (assuming loading instances
of ummanaged code is even possible!). If need be, I'll opt for the new
calling method but I'd prefer to find a (better) alternative.

I hope this made sense!!

I have been out of the AW frame for some time now, and I don't recognise a
fair few of the names that post in the newsgroups these days, so I don't
really know who's knowledgable in what areas. I've also been away from the
SDK for the same period, so please forgive me if I'm a bit out of touch with
where AW is at the moment.

BTW ... what's the deal with AW_UNIVERSE_RENEWAL_CHARGE? Does this attribute
exist (as described in the SDK documentation for
AW_EVENT_UNIVERSE_ATTRIBUTES) or not (as indicated by its absence from
aw.h)?

Many thanks,

Grims.

Apr 24, 2006, 5:42pm

[View Quote] > Just a quick question ... I've been trying to think my way around this, but
> I keep coming to the same conclusion and I'd just like to check with those
> that may know or have an opinion what their views are.
>
<snip>

To make the answer short - the AW SDK 3.6 (up to the latest build) does not support multi threading and it is not multi threading safe.

Wait for the 4.x release :)

--
Andras
"It's MY computer" (tm Steve Gibson)

Apr 25, 2006, 7:56am

Thanks Andras,

I'll sort out the rest of the grunt work inside and just keep in view the
threading option for now. Hopefully a release of the SDK with thread support
will come along before my interest starts to wane and its implemented in a
way that doesn't need too much rework in the framework.

Cheers,

Grims.

[View Quote] > To make the answer short - the AW SDK 3.6 (up to the latest build) does
> not support multi threading and it is not multi threading safe.
>
> Wait for the 4.x release :)

Jun 3, 2006, 8:19pm

So - and without any documentation its hard to tell anything really - can
build 60 of the SDK can now handle multiple threads interacting with it
(referring back to my example of two independent threads performing similar
tasks and getting themselves confused by overwriting eachother's attribute
settings and/or switching instances when running concurrently)?

There's nothing that jumps out from the aw.h, just an instance-level event
subscriber, which I would imagine most people that run multiple bots in the
same program have implemented themselves anyway on top of the old method
(although I'm not saying its not good to have this where it belongs, in the
SDK!).

Thanks

Grims

[View Quote]

1  |   Order by index