VM Semaphores and external native threads

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

VM Semaphores and external native threads

Ronie Salgado
 
Hi,

I started to make an IDE like tool in Pharo, and I have an external library for handling some asynchronous events generated in a separate thread, which I am putting in a queue that I am polling each 200 ms from a Pharo image. Currently I am using this library for handling pipes of external process (GDB with the machine interface), and next I am going to add support for inotify.

I know that I can remove this polling each 200 ms by implementing a mechanism for registering multiples event handlers that are called by ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this places, which asks SDL2 for the presence of events and it signals VM Semaphore. However, since in this case I have control of the code in the external thread, I would like to just signal the VM Semaphore in this external thread to avoid this polling. So here is my question:

Is signaling a VM Semaphore thread safe? In case it is not, how much work would require to make it thread safe.

Best regards,
Ronie
Reply | Threaded
Open this post in threaded view
|

Re: VM Semaphores and external native threads

David T. Lewis
 
On Wed, Nov 08, 2017 at 10:56:50PM -0300, Ronie Salgado wrote:

>  
> Hi,
>
> I started to make an IDE like tool in Pharo, and I have an external library
> for handling some asynchronous events generated in a separate thread, which
> I am putting in a queue that I am polling each 200 ms from a Pharo image.
> Currently I am using this library for handling pipes of external process
> (GDB with the machine interface), and next I am going to add support for
> inotify.
>
> I know that I can remove this polling each 200 ms by implementing a
> mechanism for registering multiples event handlers that are called by
> ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this
> places, which asks SDL2 for the presence of events and it signals VM
> Semaphore. However, since in this case I have control of the code in the
> external thread, I would like to just signal the VM Semaphore in this
> external thread to avoid this polling. So here is my question:
>
> Is signaling a VM Semaphore thread safe? In case it is not, how much work
> would require to make it thread safe.
>
> Best regards,
> Ronie

Do you mean #signalSemaphoreWithWindex: which signals a Smalltalk semaphore
from the VM or plugin? My expectation is that this is intended to be called
from the main interpreter thread, and would not be thread safe with respect
to calling it from other threads running in the VM. I expect that you would
need to synchronize access to signalSemaphoreWithIndex: in order to make this
work.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: VM Semaphores and external native threads

johnmci
 
In the past the semaphore signaling logic was written to be mostly thread safe because I was driving it from a UI thread and we had to queue requests as the VM only processed the queue every N ms. Don’t know where it sits today as it was rewritten.

Sent from my iPhone

> On Nov 8, 2017, at 18:32, David T. Lewis <[hidden email]> wrote:
>
>
>> On Wed, Nov 08, 2017 at 10:56:50PM -0300, Ronie Salgado wrote:
>>
>> Hi,
>>
>> I started to make an IDE like tool in Pharo, and I have an external library
>> for handling some asynchronous events generated in a separate thread, which
>> I am putting in a queue that I am polling each 200 ms from a Pharo image.
>> Currently I am using this library for handling pipes of external process
>> (GDB with the machine interface), and next I am going to add support for
>> inotify.
>>
>> I know that I can remove this polling each 200 ms by implementing a
>> mechanism for registering multiples event handlers that are called by
>> ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this
>> places, which asks SDL2 for the presence of events and it signals VM
>> Semaphore. However, since in this case I have control of the code in the
>> external thread, I would like to just signal the VM Semaphore in this
>> external thread to avoid this polling. So here is my question:
>>
>> Is signaling a VM Semaphore thread safe? In case it is not, how much work
>> would require to make it thread safe.
>>
>> Best regards,
>> Ronie
>
> Do you mean #signalSemaphoreWithWindex: which signals a Smalltalk semaphore
> from the VM or plugin? My expectation is that this is intended to be called
> from the main interpreter thread, and would not be thread safe with respect
> to calling it from other threads running in the VM. I expect that you would
> need to synchronize access to signalSemaphoreWithIndex: in order to make this
> work.
>
> Dave
>
Reply | Threaded
Open this post in threaded view
|

Re: VM Semaphores and external native threads

Denis Kudriashov
 
I am wondering, external semaphores are used in sockets. I suppose that it must be thread safe for that case.

2017-11-09 4:01 GMT+01:00 John McIntosh <[hidden email]>:

In the past the semaphore signaling logic was written to be mostly thread safe because I was driving it from a UI thread and we had to queue requests as the VM only processed the queue every N ms. Don’t know where it sits today as it was rewritten.

Sent from my iPhone

> On Nov 8, 2017, at 18:32, David T. Lewis <[hidden email]> wrote:
>
>
>> On Wed, Nov 08, 2017 at 10:56:50PM -0300, Ronie Salgado wrote:
>>
>> Hi,
>>
>> I started to make an IDE like tool in Pharo, and I have an external library
>> for handling some asynchronous events generated in a separate thread, which
>> I am putting in a queue that I am polling each 200 ms from a Pharo image.
>> Currently I am using this library for handling pipes of external process
>> (GDB with the machine interface), and next I am going to add support for
>> inotify.
>>
>> I know that I can remove this polling each 200 ms by implementing a
>> mechanism for registering multiples event handlers that are called by
>> ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this
>> places, which asks SDL2 for the presence of events and it signals VM
>> Semaphore. However, since in this case I have control of the code in the
>> external thread, I would like to just signal the VM Semaphore in this
>> external thread to avoid this polling. So here is my question:
>>
>> Is signaling a VM Semaphore thread safe? In case it is not, how much work
>> would require to make it thread safe.
>>
>> Best regards,
>> Ronie
>
> Do you mean #signalSemaphoreWithWindex: which signals a Smalltalk semaphore
> from the VM or plugin? My expectation is that this is intended to be called
> from the main interpreter thread, and would not be thread safe with respect
> to calling it from other threads running in the VM. I expect that you would
> need to synchronize access to signalSemaphoreWithIndex: in order to make this
> work.
>
> Dave
>

Reply | Threaded
Open this post in threaded view
|

Re: VM Semaphores and external native threads

Nicolas Cellier
 

2017-11-09 10:13 GMT+01:00 Denis Kudriashov <[hidden email]>:
 
I am wondering, external semaphores are used in sockets. I suppose that it must be thread safe for that case.

2017-11-09 4:01 GMT+01:00 John McIntosh <[hidden email]>:

In the past the semaphore signaling logic was written to be mostly thread safe because I was driving it from a UI thread and we had to queue requests as the VM only processed the queue every N ms. Don’t know where it sits today as it was rewritten.

Sent from my iPhone

> On Nov 8, 2017, at 18:32, David T. Lewis <[hidden email]> wrote:
>
>
>> On Wed, Nov 08, 2017 at 10:56:50PM -0300, Ronie Salgado wrote:
>>
>> Hi,
>>
>> I started to make an IDE like tool in Pharo, and I have an external library
>> for handling some asynchronous events generated in a separate thread, which
>> I am putting in a queue that I am polling each 200 ms from a Pharo image.
>> Currently I am using this library for handling pipes of external process
>> (GDB with the machine interface), and next I am going to add support for
>> inotify.
>>
>> I know that I can remove this polling each 200 ms by implementing a
>> mechanism for registering multiples event handlers that are called by
>> ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this
>> places, which asks SDL2 for the presence of events and it signals VM
>> Semaphore. However, since in this case I have control of the code in the
>> external thread, I would like to just signal the VM Semaphore in this
>> external thread to avoid this polling. So here is my question:
>>
>> Is signaling a VM Semaphore thread safe? In case it is not, how much work
>> would require to make it thread safe.
>>
>> Best regards,
>> Ronie
>
> Do you mean #signalSemaphoreWithWindex: which signals a Smalltalk semaphore
> from the VM or plugin? My expectation is that this is intended to be called
> from the main interpreter thread, and would not be thread safe with respect
> to calling it from other threads running in the VM. I expect that you would
> need to synchronize access to signalSemaphoreWithIndex: in order to make this
> work.
>
> Dave
>