Scenario: What will happen?

[Jim Locker]

Suppose, upon starting a simpol program, I define an object and initialize it in some appropriate fashion. Then, I spawn a new thread, and pass a reference to this object so that the new thread can use what is in it. Then, I terminate the thread that created the object. Will the object continue to exist because there is a valid reference to it? Or does the reference become invalid? Also, how can I pass an object by value rather than by reference, for those circumstances where this would be appropriate?

[Michael]

Jim wrote:
> Suppose, upon starting a simpol program, I define an object and
> initialize it in some appropriate fashion.
>
> Then, I spawn a new thread, and pass a reference to this object so
> that the new thread can use what is in it.
>
> Then, I terminate the thread that created the object.
>
> Will the object continue to exist because there is a valid reference
> to it? Or does the reference become invalid?

As long as a reference to an object exists, it will continue to exist.
Once the last reference is gone, the object is destroyed and the memory
freed. There is no garbage collection.

> Also, how can I pass an object by value rather than by reference, for
> those circumstances where this would be appropriate?

If you want to pass a scalar type (integer, number, boolean, blob, or
string), the easiest way is to do this:

string s

s = "hello"
foo(string.new(s))

There is no method for passing a copy of a complex object. Also, in a
multi-threaded environment, it is important to be aware of the fact that
concurrent threads may be modifying the same common object. If this is
likely to happen, you can control access to the object (or sections of
it) by inserting lock1 objects into the object as well. Before accessing
the object or a specific part, you can get a lock on the lock1 object.
If it fails, you know that you cannot currently safely access the object
or section.

Ciao, Neil

[Jim Locker]

of course, the fact that I will be using multiple threads is the reason I
was asking about pass by value vs pass by reference.

Is the taking of a lock guaranteed to be atomic, such that I can't get
into a problem if two threads simultaneously try to take a lock (which
potentially is possible on a multiprocessor system)? Low probability
event, sure. But if it can happen, it will, and corrupting data is to be
avoided at all costs.

[Michael]

Jim wrote:
> of course, the fact that I will be using multiple threads is the
> reason I was asking about pass by value vs pass by reference.
>
> Is the taking of a lock guaranteed to be atomic, such that I can't
> get into a problem if two threads simultaneously try to take a lock
> (which potentially is possible on a multiprocessor system)? Low
> probability event, sure. But if it can happen, it will, and
> corrupting data is to be avoided at all costs.
>
SIMPOL's threading is implemented internally, not using system threads.
As such SIMPOL would handle the thread concurrency anyway, but the call
to the lock1 object's lock() function is atomic. Only one will succeed.

Ciao, Neil

[Jim Locker]

Neil Robinson wrote:

> Jim wrote:
>> of course, the fact that I will be using multiple threads is the
>> reason I was asking about pass by value vs pass by reference.
>>
>> Is the taking of a lock guaranteed to be atomic, such that I can't
>> get into a problem if two threads simultaneously try to take a lock
>> (which potentially is possible on a multiprocessor system)? Low
>> probability event, sure. But if it can happen, it will, and
>> corrupting data is to be avoided at all costs.
>>
> SIMPOL's threading is implemented internally, not using system threads.
> As such SIMPOL would handle the thread concurrency anyway, but the call
> to the lock1 object's lock() function is atomic. Only one will succeed.

> Ciao, Neil

Does that mean that a simpol application will not take advantage of
multiple processors?

[Jim Locker]

Neil Robinson wrote:

> Jim wrote:
>> of course, the fact that I will be using multiple threads is the
>> reason I was asking about pass by value vs pass by reference.
>>
>> Is the taking of a lock guaranteed to be atomic, such that I can't
>> get into a problem if two threads simultaneously try to take a lock
>> (which potentially is possible on a multiprocessor system)? Low
>> probability event, sure. But if it can happen, it will, and
>> corrupting data is to be avoided at all costs.
>>
> SIMPOL's threading is implemented internally, not using system threads.
> As such SIMPOL would handle the thread concurrency anyway, but the call
> to the lock1 object's lock() function is atomic. Only one will succeed.

> Ciao, Neil

Actually, I am a bit surprised you are not just putting a wrapper around
pthreads.

[Michael]

Jim wrote:
> Neil Robinson wrote:
>
>> Jim wrote:
>>> of course, the fact that I will be using multiple threads is the
>>> reason I was asking about pass by value vs pass by reference.
>>>
>>> Is the taking of a lock guaranteed to be atomic, such that I
>>> can't get into a problem if two threads simultaneously try to
>>> take a lock (which potentially is possible on a multiprocessor
>>> system)? Low probability event, sure. But if it can happen, it
>>> will, and corrupting data is to be avoided at all costs.
>>>
>> SIMPOL's threading is implemented internally, not using system
>> threads. As such SIMPOL would handle the thread concurrency anyway,
>> but the call to the lock1 object's lock() function is atomic. Only
>> one will succeed.
>
>> Ciao, Neil
>
> Does that mean that a simpol application will not take advantage of
> multiple processors?
>

A single SIMPOL process will only run on one CPU. If you design an
application that uses multiple programs, each will potentially run on a
separate CPU. This is the other side of our design decision about
ensuring that SIMPOL is multi-threaded even on systems that would not
provide a reliable threading library. There is some planning for
allowing SIMPOL programs to run other SIMPOL programs (without using
!execute() ) and in that case they might run on different CPUs.

Ciao, Neil

[Michael]

Jim wrote:
> Neil Robinson wrote:
>
>> Jim wrote:
>>> of course, the fact that I will be using multiple threads is the
>>> reason I was asking about pass by value vs pass by reference.
>>>
>>> Is the taking of a lock guaranteed to be atomic, such that I
>>> can't get into a problem if two threads simultaneously try to
>>> take a lock (which potentially is possible on a multiprocessor
>>> system)? Low probability event, sure. But if it can happen, it
>>> will, and corrupting data is to be avoided at all costs.
>>>
>> SIMPOL's threading is implemented internally, not using system
>> threads. As such SIMPOL would handle the thread concurrency anyway,
>> but the call to the lock1 object's lock() function is atomic. Only
>> one will succeed.
>
>> Ciao, Neil
>
> Actually, I am a bit surprised you are not just putting a wrapper
> around pthreads.
>

The reason for that is that our early experimentation with pthreads was
less than satisfactory, and we also found that pthreads were not a
guaranteed presence on any given Linux installation.

Freeware products can get away with that (oh it doesn't work unless…),
but we can't.

Ciao, Neil

[Jim Locker]

Pthreads can be deployed in Windows also.

But, yes. It is done in a library. And the library doesn't have to be
there. Personally, I've never run across an installation that didn't have
it available but that doesn't mean there couldn't be one because there
could be one – just don't provide the library.

In that event, a LOT of stuff would break but it would be OK for an
appropriate embedded installation.

I don't know about issues with pthreads; they seem to work very well. You
just have to know how to use them, and you do have to be careful about
synchronization. Pthreads does seem to cause a lot of religious wars in
the unix community; their non-deterministic nature gets some people's
bowels into a complete uproar, and they do make debugging far more
entertaining if you don't design your application right.

Simpol threads are certainly simpler, but not quite as powerful. So far,
on my form-based solution, threads are working fine. We'll see how it
goes when I implement some of my jobs that run at specific times (time of
day) and we'll see if everything is adequately serviced while one of those
jobs is running.

[Michael]

Jim wrote:
> Simpol threads are certainly simpler, but not quite as powerful. So
> far, on my form-based solution, threads are working fine. We'll see
> how it goes when I implement some of my jobs that run at specific
> times (time of day) and we'll see if everything is adequately
> serviced while one of those jobs is running.
Should be okay. See the timer.sml library (source included). I use it
quite regularly and reliably.

Ciao, Neil

[Author]

Posts