YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

Some help with threads...
Options
Previous Topic Next Topic
Tricky
#1 Posted : Tuesday, July 26, 2005 3:38:26 AM(UTC)
Rank: Member

Groups: Registered
Joined: 6/24/2005(UTC)
Posts: 12

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Hello everybody,

 I fear that the question I'm going to make falls in the RTFM class, but I was not able to find the info I need, therefore if somebody can give me links or suggestion to study the matter by myself I'll be more than happy.

Anyway the problems is this. I created an app where squirrel takes case of almost everything. The app is a kind of "applet builder" and Squirrel can open files, script the UI, write DB, ecc. ecc.

Now the problem I'm facing is this:

I want to use a library that creates several OS threads. When some event happens the thread will call a C++ class method.

I'd like to call squirrel in this method, that is in a thread different from the main.

What is the best solution?

The first idea that comes to mind is controlling the access to Squirrel througu a mutex. I remember reading something similar about Lua.



Well I'm a bit clueless.



Thanks for any hints,

 Riccardo
Back to top
fagiano
#2 Posted : Friday, July 29, 2005 7:24:07 AM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 825

Thanks: 0 times
Was thanked: 36 time(s) in 29 post(s)
Mmh that's an hairy problem. Squirrel is not thread aware because usually games logical flow is single threaded. So you have to handle  resource locking by yourself.


Basically you must be sure that while thread A is running squirrel, thread B is not; and viceversa. Running squirrel code in 2 threads at the same time (if they uses the same VM) is unsafe.


in the best case you should be able to solve it like this


<pre>EnterCriticalSection()</pre>
<pre>sq_call(........)</pre>
<pre>...other Squirrel code</pre>
<pre>LeaveCriticalSection()</pre>
but is very app dependent


another more elegant solution is using some sort of message queue and broadcast you events/call from a single thread, roughtly like windows handles thread messages. In this case have to evaluate if is worthed the additional complexity added to you system.


Alberto
Back to top
Tricky
#3 Posted : Saturday, July 30, 2005 11:50:12 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/24/2005(UTC)
Posts: 12

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Alberto, thank you very much for your reply (ant patience!).

Anyway, one question more, sorry ;-).

Your answer is exactly what I've been thinking, but then another question pops up: what is then, the usage pattern of sq_newthread? I do not know if I can explain me well, what I'd like to know is when sq_newthread should be used, what kind of problem does it address?

Looking around the 'net, I've found an article about Lua threads, where it says that is possible to compile Lua specifying an implementation for a lua_lock/unlock call ( http://lua-users.org/wiki/ThreadsTutorial ).

What are your thoughts about this? DO you plan to add such a features in squirrel? (look, I'm not saying that I want this, but rather, I'm thrying to understand the mysterious (for me) world of multithreading in Squirrel/Lua).



Thanks again for the good work, I'm using squirrel extensively in one of my projects, and it is really fun to use!



Riccardo
Back to top
fagiano
#4 Posted : Sunday, July 31, 2005 11:06:15 AM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 825

Thanks: 0 times
Was thanked: 36 time(s) in 29 post(s)
sq_newthread() creates a new VM that can share data with the one created with sq_open(). In squirrel te word thread stays for 'cooperative thread' (Aka coroutine) so nothing related to OS threads.


Lua as a similar architecture, what they do is having all api calls wrapped in 2 macros; lock() and unlock() and a critical section associated to each VM. then for each OS thread you create a VM.


I could do the same for squirrel, it wouldn't be a big deal except for testing. I'm personally not a big fan of multithreading, at least when it involves data sharing, so I haven't done any work in that direction so far. I agree that soon or later wouldn't be a bad idea; expecaily with all this dual core bulls%#t on the way.


ciao


Alberto
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.095 seconds.