Multi thread VA Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Multi thread VA Smalltalk

Louis LaBrunda
Hi Smalltalkers,

I don't know for sure but I think Instantiations is getting close to having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may be faster than the current 32 bit VM, that would be great.

I'm hoping the next step will be a multi thread VM.  I know there are a lot of ways to do/define this.  I for one would be happy with a simple thread per fork design.  I already use semaphores to protect objects that more than one fork have write access to.  Unless I'm missing something (and I might be - I'm getting old and I'm sleep deprived) semaphores should be good enough to protect two forks/threads from messing up an object they both write to.

I'm thinking this kind of VM would solve my problem (defined in another post) with the download of a file being blocked while the user is thinking about where to save the file.  I have also seen a problem (that I haven't reported) with GUI programs that have some socket transfers and handshaking going on in the background and the user drops down a menu and lets the mouse hover there while he thinks about what to do, the socket doesn't seem to get any love and times out.  I think the common cause here is that both the menu and save file prompt are Windows widgets and that there use blocks the thread.  This is just a guess.

Anyway, back to a multi threaded VM, what's does every one think?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Instantiations mailing list
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

0xF93E9756.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Seth Berman
Hi Lou, Martin,

Martin is right...this approach as you described would not be appropriate for our product.
@Martin - "Perhaps what is needed is a better callback support in VA".
- Can you elaborate?

-- Seth

On Friday, July 15, 2016 at 12:06:27 PM UTC-4, Marten Feldtmann wrote:
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
Hi Seth,

I don't know enough about C and Windows threads to really know what I'm talking about.  So, let me ask a few questions.  Exactly what is meant by not being thread-safe?  If two forks are each running in their own thread, aren't semaphores enough to protect things or is other under the covers stuff like garbage collection vulnerable?

Lou


On Friday, July 15, 2016 at 12:39:36 PM UTC-4, Seth Berman wrote:
Hi Lou, Martin,

Martin is right...this approach as you described would not be appropriate for our product.
@Martin - "Perhaps what is needed is a better callback support in VA".
- Can you elaborate?

-- Seth

On Friday, July 15, 2016 at 12:06:27 PM UTC-4, Marten Feldtmann wrote:
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Instantiations mailing list
There are two points: supporting external concurrent threads (which VA
does) and multi threading Smalltalk (having several Smalltalk threads
executing independent Smalltalk threads).

Some infos about threads in VA can you see here in my podcasts:

https://www.youtube.com/watch?v=tciDPsrgGQ4&feature=youtu.be

I'm not aware of any (?) Smalltalk having multiple Smalltalk execution
threads running (in native threads). If you go this way, you have the
problems in all languages: base libraries are not threads safe. Other
languages like C# or Java have the same problem.

Marten

Am 15.07.2016 um 20:05 schrieb Louis LaBrunda:
> Hi Seth,
>
> I don't know enough about C and Windows threads to really know what I'm
> talking about.  So, let me ask a few questions.  Exactly what is meant
> by not being thread-safe?  If two forks are each running in their own
> thread, aren't semaphores enough to protect things or is other under the
> covers stuff like garbage collection vulnerable?
>

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

0xF93E9756.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Seth Berman
In reply to this post by Louis LaBrunda
Hi Lou,

Yeah, no problem.
The "semaphores" I think you are referring to are the Smalltalk sempahore constructs...used for coordinating the cooperative green thread scheduler in VA.  You can think of it as being a bit preemptive (i.e. interrupts) but this is tightly controlled by the vm.  For example, during jump bytecodes the async message queue is checked which may fire an interrupt.  Sometimes you will see things like Processor yield to force that ST process to give up control manually.

Modern OS threads are scheduled by the OS...and can give up control at any time.  Even the completion of a smalltalk semaphore signal or wait may not happen before the OS thread associated with that ST process yields, is put back on the scheduler, and another OS thread executes....perhaps one that proceeds past your logically coordinated semaphore guard.

Python implements the GIL (global interpreter lock) in the vm to try and do what you are roughly suggesting...but it's not considered a favored solution...and you would need VM assistance for this.

True multi-threaded vm's like java require a lot of concurrency constructs, memory management complexity that can handle multiple threads allocating objects at the same time in a common heap, GC safe points for coordination of GC, and lots of new classes of bugs that I would not look forward to supporting.
if you don't get it right (which as an ex-Java developer....I know to be the case.  In fact my favorite story was analyzing performance problems on a java system where the developers knew they didn't understand concurrency so they made everything the atomic form of whatever object they needed...AtomicInteger, AtomicLong, AtomicBoolean.  So it was basically a system that couldn't get anything done because the contention levels were astronomically high...it would have been faster just to keep it serial).

In the vm, we have one interpreter and one logical heap.  If it were to be extended, I would favor something more like Dart isolates which have separate heaps...separate execution engines...communicate efficiently via message passing.
If the recent re-popularization of functional languages has taught us anything...it's that coordinating shared state between native threads is hard...just take it out of the equation.

-- Seth

On Friday, July 15, 2016 at 2:05:25 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I don't know enough about C and Windows threads to really know what I'm talking about.  So, let me ask a few questions.  Exactly what is meant by not being thread-safe?  If two forks are each running in their own thread, aren't semaphores enough to protect things or is other under the covers stuff like garbage collection vulnerable?

Lou


On Friday, July 15, 2016 at 12:39:36 PM UTC-4, Seth Berman wrote:
Hi Lou, Martin,

Martin is right...this approach as you described would not be appropriate for our product.
@Martin - "Perhaps what is needed is a better callback support in VA".
- Can you elaborate?

-- Seth

On Friday, July 15, 2016 at 12:06:27 PM UTC-4, Marten Feldtmann wrote:
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
Hi Seth,

Thanks for the explanation.  I like the separate heaps...separate execution engines...communicating efficiently via message passing idea.  With desktop computers and things as small as a Raspberry Pi running four cores, it would be nice if VA Smalltalk could do more that one thing at a time.  In the mean time maybe my suggestion of pushing more external (windows and other DLL) call into their own thread would help.  Of course this would have to be done in a safe way, insuring that limited Smalltalk memory is touched by the extra thread.

Lou


On Friday, July 15, 2016 at 2:45:21 PM UTC-4, Seth Berman wrote:
Hi Lou,

Yeah, no problem.
The "semaphores" I think you are referring to are the Smalltalk sempahore constructs...used for coordinating the cooperative green thread scheduler in VA.  You can think of it as being a bit preemptive (i.e. interrupts) but this is tightly controlled by the vm.  For example, during jump bytecodes the async message queue is checked which may fire an interrupt.  Sometimes you will see things like Processor yield to force that ST process to give up control manually.

Modern OS threads are scheduled by the OS...and can give up control at any time.  Even the completion of a smalltalk semaphore signal or wait may not happen before the OS thread associated with that ST process yields, is put back on the scheduler, and another OS thread executes....perhaps one that proceeds past your logically coordinated semaphore guard.

Python implements the GIL (global interpreter lock) in the vm to try and do what you are roughly suggesting...but it's not considered a favored solution...and you would need VM assistance for this.

True multi-threaded vm's like java require a lot of concurrency constructs, memory management complexity that can handle multiple threads allocating objects at the same time in a common heap, GC safe points for coordination of GC, and lots of new classes of bugs that I would not look forward to supporting.
if you don't get it right (which as an ex-Java developer....I know to be the case.  In fact my favorite story was analyzing performance problems on a java system where the developers knew they didn't understand concurrency so they made everything the atomic form of whatever object they needed...AtomicInteger, AtomicLong, AtomicBoolean.  So it was basically a system that couldn't get anything done because the contention levels were astronomically high...it would have been faster just to keep it serial).

In the vm, we have one interpreter and one logical heap.  If it were to be extended, I would favor something more like Dart isolates which have separate heaps...separate execution engines...communicate efficiently via message passing.
If the recent re-popularization of functional languages has taught us anything...it's that coordinating shared state between native threads is hard...just take it out of the equation.

-- Seth

On Friday, July 15, 2016 at 2:05:25 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I don't know enough about C and Windows threads to really know what I'm talking about.  So, let me ask a few questions.  Exactly what is meant by not being thread-safe?  If two forks are each running in their own thread, aren't semaphores enough to protect things or is other under the covers stuff like garbage collection vulnerable?

Lou


On Friday, July 15, 2016 at 12:39:36 PM UTC-4, Seth Berman wrote:
Hi Lou, Martin,

Martin is right...this approach as you described would not be appropriate for our product.
@Martin - "Perhaps what is needed is a better callback support in VA".
- Can you elaborate?

-- Seth

On Friday, July 15, 2016 at 12:06:27 PM UTC-4, Marten Feldtmann wrote:
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Seth Berman
Hi Lou,

Well the constrains of the windows message queue...what thread it's called on...means the architecture would likely have to change in a significant way.

But "other DLL" concurrency can be achieved now....that's what async calls (thread pools) and static future (dedicated separate thread) are for.  They give you concurrency availability in native calls in a way that keeps the smalltalk processor assumptions valid.
I just tested some cryptography stuff where I spawned off 5 smalltalk processes that each do heavy encryption and base64 encoding on incoming data.  On my i7, I was able to keep 6 threads (4 cores - each one hyperthreaded) extremely busy.  It completed in @25% the time of the same application running with no forks.

The problem is running bytecodes (and everything they end up doing/impacting) in a concurrent way....that's a completely different story.

Good thoughts on your part...thanks.

-- Seth

On Friday, July 15, 2016 at 3:31:03 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Thanks for the explanation.  I like the separate heaps...separate execution engines...communicating efficiently via message passing idea.  With desktop computers and things as small as a Raspberry Pi running four cores, it would be nice if VA Smalltalk could do more that one thing at a time.  In the mean time maybe my suggestion of pushing more external (windows and other DLL) call into their own thread would help.  Of course this would have to be done in a safe way, insuring that limited Smalltalk memory is touched by the extra thread.

Lou


On Friday, July 15, 2016 at 2:45:21 PM UTC-4, Seth Berman wrote:
Hi Lou,

Yeah, no problem.
The "semaphores" I think you are referring to are the Smalltalk sempahore constructs...used for coordinating the cooperative green thread scheduler in VA.  You can think of it as being a bit preemptive (i.e. interrupts) but this is tightly controlled by the vm.  For example, during jump bytecodes the async message queue is checked which may fire an interrupt.  Sometimes you will see things like Processor yield to force that ST process to give up control manually.

Modern OS threads are scheduled by the OS...and can give up control at any time.  Even the completion of a smalltalk semaphore signal or wait may not happen before the OS thread associated with that ST process yields, is put back on the scheduler, and another OS thread executes....perhaps one that proceeds past your logically coordinated semaphore guard.

Python implements the GIL (global interpreter lock) in the vm to try and do what you are roughly suggesting...but it's not considered a favored solution...and you would need VM assistance for this.

True multi-threaded vm's like java require a lot of concurrency constructs, memory management complexity that can handle multiple threads allocating objects at the same time in a common heap, GC safe points for coordination of GC, and lots of new classes of bugs that I would not look forward to supporting.
if you don't get it right (which as an ex-Java developer....I know to be the case.  In fact my favorite story was analyzing performance problems on a java system where the developers knew they didn't understand concurrency so they made everything the atomic form of whatever object they needed...AtomicInteger, AtomicLong, AtomicBoolean.  So it was basically a system that couldn't get anything done because the contention levels were astronomically high...it would have been faster just to keep it serial).

In the vm, we have one interpreter and one logical heap.  If it were to be extended, I would favor something more like Dart isolates which have separate heaps...separate execution engines...communicate efficiently via message passing.
If the recent re-popularization of functional languages has taught us anything...it's that coordinating shared state between native threads is hard...just take it out of the equation.

-- Seth

On Friday, July 15, 2016 at 2:05:25 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

I don't know enough about C and Windows threads to really know what I'm talking about.  So, let me ask a few questions.  Exactly what is meant by not being thread-safe?  If two forks are each running in their own thread, aren't semaphores enough to protect things or is other under the covers stuff like garbage collection vulnerable?

Lou


On Friday, July 15, 2016 at 12:39:36 PM UTC-4, Seth Berman wrote:
Hi Lou, Martin,

Martin is right...this approach as you described would not be appropriate for our product.
@Martin - "Perhaps what is needed is a better callback support in VA".
- Can you elaborate?

-- Seth

On Friday, July 15, 2016 at 12:06:27 PM UTC-4, Marten Feldtmann wrote:
No, not any more.

Stay with your single thread. It keeps the implementation much simpler
and most of the Smalltalk library is not threadsafe either - offering
therefore a potential risk for lots of other problems.

Perhaps what is needed is a better callback support in VA (at least
under Windows).

And VASmalltalk has a pretty good framework (SST), but actually no
already working infrastructure how to start up multi-processing (and not
multi-threading).

Marten

Am 15.07.2016 um 16:42 schrieb Louis LaBrunda:

> Hi Smalltalkers,
>
> I don't know for sure but I think Instantiations is getting close to
> having a 64 bit VA Smalltalk.  I hear that both the 32 & 64 bit VMs may
> be faster than the current 32 bit VM, that would be great.
>
> I'm hoping the next step will be a multi thread VM.  I know there are a
> lot of ways to do/define this.  I for one would be happy with a simple
> thread per fork design.  I already use semaphores to protect objects
> that more than one fork have write access to.  Unless I'm missing
> something (and I might be - I'm getting old and I'm sleep deprived)
> semaphores should be good enough to protect two forks/threads from
> messing up an object they both write to.
>
> I'm thinking this kind of VM would solve my problem (defined in another
> post) with the download of a file being blocked while the user is
> thinking about where to save the file.  I have also seen a problem (that
> I haven't reported) with GUI programs that have some socket transfers
> and handshaking going on in the background and the user drops down a
> menu and lets the mouse hover there while he thinks about what to do,
> the socket doesn't seem to get any love and times out.  I think the
> common cause here is that both the menu and save file prompt are Windows
> widgets and that there use blocks the thread.  This is just a guess.
>
> Anyway, back to a multi threaded VM, what's does every one think?
>



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Instantiations mailing list
And if you connect your VASmalltalk images via 0MQ libraries, all IP
communications are done in external c threads and even more cores have
work to do.

There ARE ways to solve the threading problems ....

Marten

Am 15.07.2016 um 21:44 schrieb Seth Berman:

> data.  On my i7, I was able to keep 6 threads (4 cores - each one
> hyperthreaded) extremely busy.  It completed in @25% the time of the
> same application running with no forks.
>

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

0xF93E9756.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
In reply to this post by Seth Berman
Hi Seth,

On Friday, July 15, 2016 at 3:44:22 PM UTC-4, Seth Berman wrote:
Hi Lou,

Well the constrains of the windows message queue...what thread it's called on...means the architecture would likely have to change in a significant way.

But "other DLL" concurrency can be achieved now....that's what async calls (thread pools) and static future (dedicated separate thread) are for.  They give you concurrency availability in native calls in a way that keeps the smalltalk processor assumptions valid.
I just tested some cryptography stuff where I spawned off 5 smalltalk processes that each do heavy encryption and base64 encoding on incoming data.  On my i7, I was able to keep 6 threads (4 cores - each one hyperthreaded) extremely busy.  It completed in @25% the time of the same application running with no forks.

The problem is running bytecodes (and everything they end up doing/impacting) in a concurrent way....that's a completely different story.

Good thoughts on your part...thanks.

-- Seth
 
This is very interesting and impressive.

"...the constrains of the windows message queue...what thread it's called on..."  Here's a thought (probably crazy) could the VM have a small companion program that ran the things that Windows would block on and return the result to the VM?  As I think about this, I expect it is not worth the effort.  Too many potential problems with parents of windows, Z order and cursor.

When "the windows message queue" is blocked, does it block all threads?

Does the bytecode processing need to be in the main thread, the same thread as the "the windows message queue"?


Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
Hi Seth,

How hard/nuts would it be to have the bytecode processing engine of the VM to be a headless program?  Kind of like the Windows NT service VM (but not an NT service).  Then there would be a regular (more or less) window program that would call the VM to do everything except the GUI window stuff.  Of course the connection between the two programs would need to be fast.

This could be a first step to having multiple VMs running the same image (or different) and communicating with each other.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Seth Berman
Hi Lou,

"How hard/nuts would it be to have the bytecode processing engine of the VM to be a headless program?"
- Not hard at all...that's what it is now:)  The smalltalk image contains the GUI bootstrap and handling...the vm does not.

"Then there would be a regular (more or less) window program that would call the VM to do everything except the GUI window stuff"
- I don't think I understand exactly where you are headed...and all my guesses lead to a smalltalk program with horrible performance so I guess I would say
  that, in general, a smalltalk program running on a virtual machine has the same constraints as a native program running on an OS hosted on a real machine.
  Both provide task scheduling, memory management, serve as a gateway to other services/capabilities, execute instructions as quickly as possible.
  If I understand your suggestions correctly....one could never make this fast.

-- Seth

On Monday, July 18, 2016 at 9:43:32 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

How hard/nuts would it be to have the bytecode processing engine of the VM to be a headless program?  Kind of like the Windows NT service VM (but not an NT service).  Then there would be a regular (more or less) window program that would call the VM to do everything except the GUI window stuff.  Of course the connection between the two programs would need to be fast.

This could be a first step to having multiple VMs running the same image (or different) and communicating with each other.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Instantiations mailing list
In reply to this post by Louis LaBrunda
Do you have something like the JavaThinClient (very old goodie) approach
in mind ?


Marten

Am 18.07.2016 um 15:43 schrieb Louis LaBrunda:

> Hi Seth,
>
> How hard/nuts would it be to have the bytecode processing engine of the
> VM to be a headless program?  Kind of like the Windows NT service VM
> (but not an NT service).  Then there would be a regular (more or less)
> window program that would call the VM to do everything except the GUI
> window stuff.  Of course the connection between the two programs would
> need to be fast.
>
> This could be a first step to having multiple VMs running the same image
> (or different) and communicating with each other.
>
> Lou
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> Visit this group at https://groups.google.com/group/va-smalltalk.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

0xF93E9756.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
In reply to this post by Seth Berman
Hi Seth and Marten,

Marten - I'm not familiar with JavaThinClient, so I'm not sure if that is what I'm aiming at.

Seth - I'm trying to break the connection between bytecode processing and the windows calls that block it.  I'm hoping two separate programs would do that.  The communication between the two would need to be reasonably fast.  That may not be possible.  There may not be any clean way for the bytecode processing VM to tell the windows GUI part what it needs to do/get with windows.

As I said this idea seem nuts and I'm the one thinking of it.  It just bothers me that everything stops because the mouse is over a menu item or a file save/open select window is open.

I have built progress windows with a cancel option, so I think I could build a file select window that wouldn't block but it is a lot of reinventing the wheel to get the simultaneity.  That wouldn't fix the menu problem but it would solve my download one.  This isn't really a big deal for me, it is just annoying as hell that it is even a problem.

And it ties into the question of how to use more than core in a Smalltalk program, which I find interesting.

Lou

On Monday, July 18, 2016 at 10:20:54 AM UTC-4, Seth Berman wrote:
Hi Lou,

"How hard/nuts would it be to have the bytecode processing engine of the VM to be a headless program?"
- Not hard at all...that's what it is now:)  The smalltalk image contains the GUI bootstrap and handling...the vm does not.

"Then there would be a regular (more or less) window program that would call the VM to do everything except the GUI window stuff"
- I don't think I understand exactly where you are headed...and all my guesses lead to a smalltalk program with horrible performance so I guess I would say
  that, in general, a smalltalk program running on a virtual machine has the same constraints as a native program running on an OS hosted on a real machine.
  Both provide task scheduling, memory management, serve as a gateway to other services/capabilities, execute instructions as quickly as possible.
  If I understand your suggestions correctly....one could never make this fast.

-- Seth

On Monday, July 18, 2016 at 9:43:32 AM UTC-4, Louis LaBrunda wrote:
Hi Seth,

How hard/nuts would it be to have the bytecode processing engine of the VM to be a headless program?  Kind of like the Windows NT service VM (but not an NT service).  Then there would be a regular (more or less) window program that would call the VM to do everything except the GUI window stuff.  Of course the connection between the two programs would need to be fast.

This could be a first step to having multiple VMs running the same image (or different) and communicating with each other.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Instantiations mailing list
The JavaThinClient was an IBM idea years ago. The GUI is running as a
JavaClient, data is collected there (in the GUI, in Forms) and then the
data is transferred and processing is done in a VASmalltalk server.

Does not seem to be successful those days ...

Marten

Am 18.07.2016 um 17:09 schrieb Louis LaBrunda:
> Hi Seth and Marten,
>
> Marten - I'm not familiar with JavaThinClient, so I'm not sure if that
> is what I'm aiming at.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

0xF93E9756.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Marten Feldtmann-4
In reply to this post by Louis LaBrunda
Well,

you are walking towards Headless ServerProgramming and GUI-Programming. The GUI program may starts several headless VMs. These VMs may be seen as worker processes for the GUI stuff. The GUI stuff may call the worker VMs to do some work.

Some points here:

* you must build the GUI image and the headless image. The clear division between headless and GUi image is at least needed under Linux. Windows is not that critical here.

* building two images during development is a time consuming task - at least with the absence of a non-gui approach to build images.

* you must build a scheduling framework, a management framework (start/stop all VMs etc .....)

* you may go the API-approach (using SST, HTTP, or other technology) or the remote object call (using SST).

* you may even consider to do have shared memory among these VMs - but that may be too difficult.

* you must find the useful task to be implemented in the worker processes.

Just some ideas ... its not, that there have been no ideas over the last two decades ..... :-)))



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

Louis LaBrunda
Thanks Marten.

On Monday, July 18, 2016 at 11:29:31 AM UTC-4, Marten Feldtmann wrote:
Well,

you are walking towards Headless ServerProgramming and GUI-Programming. The GUI program may starts several headless VMs. These VMs may be seen as worker processes for the GUI stuff. The GUI stuff may call the worker VMs to do some work.

Some points here:

* you must build the GUI image and the headless image. The clear division between headless and GUi image is at least needed under Linux. Windows is not that critical here.

* building two images during development is a time consuming task - at least with the absence of a non-gui approach to build images.

* you must build a scheduling framework, a management framework (start/stop all VMs etc .....)

* you may go the API-approach (using SST, HTTP, or other technology) or the remote object call (using SST).

* you may even consider to do have shared memory among these VMs - but that may be too difficult.

* you must find the useful task to be implemented in the worker processes.

Just some ideas ... its not, that there have been no ideas over the last two decades ..... :-)))



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi thread VA Smalltalk

vvm13xyz xyz
Hello.

See also Cincom Polycephaly (MatriX).

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.