- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

On 24/03/14 18:57, Alexandre Bergel wrote: >>> Any idea what is the cost of using a semaphore? Inserting the >>> expression "anOrderedCollection add: 42â in a semaphore surely >>> make the expression slower. Any idea how much slower? >> >> Can you elaborate a little on the problem. > > I am working on a memory model for expandable collection in Pharo. > Currently, OrderedCollection, Dictionary and other expandable > collections use a internal array to store their data. My new > collection library recycle these array instead of letting the garbage > collector dispose them. I simply insert the arrays in an ordered > collection when an array is not necessary anymore. And I remove one > when I need one. > Just out of curiosity, why do you do that? I would say is better throw them away (in most cases) Jan

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

>> Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? > > Can you elaborate a little on the problem. I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one. At the end, #add: and #remove: are performed on these polls of arrays. I havenât been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection newâ can pick an element of my global collection. I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes: > Your granularity does not seem to be of the right level. > Covering a single #add: operations is most probably rather fine grained, and might not give you the guarantees you would expect. > What exactly do you want to achieve? > How many Smalltalk processes are interacting with that collection? How many consumer/producer do you have? Basically, all the processes may access my global polls by inserting or removing elements. > And well, on the standard priority, you normally got cooperative scheduling anyway. So, it depends on what you are doing whether there is a real issue. > And if you donât want to use a semaphore, there are also other mechanism. I think, there should be something like âexecute uninterruptibleâ for a block. Think that raises the priority of the processes to the highest level for the execution of the block, if I remember correctly. What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far. Alexandre > > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

On 24/03/14 18:20, Alexandre Bergel wrote: >>> My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? >> >> I don't think so. AFAIK interrupts are checked on message sends and on >> backward jumps (because of inlined loops just like in your example). >> >> So context switch may happen on each send... > > Ah yes!! I missed this case. > Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? > Not really sure, since #signal and #wait are primitives, but simple benchmark should do it :-) However, you may want to use recursion lock (sometimes called monitor - in Pharo class Monitor) which allows for recursion. Otherwise you may get a nice deadlock if your code recurs. Cost of recursion lock could be reduced to couple machine instructions (if there's no contention), if done properly. The implementation of Monitor in Pharo seems to be way, way more costly than few instructions. Jan

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Stefan Marr

Hi Alexandre: On 24 Mar 2014, at 19:20, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? Can you elaborate a little on the problem. Your granularity does not seem to be of the right level. Covering a single #add: operations is most probably rather fine grained, and might not give you the guarantees you would expect. What exactly do you want to achieve? How many Smalltalk processes are interacting with that collection? How many consumer/producer do you have? And well, on the standard priority, you normally got cooperative scheduling anyway. So, it depends on what you are doing whether there is a real issue. And if you donât want to use a semaphore, there are also other mechanism. I think, there should be something like âexecute uninterruptibleâ for a block. Think that raises the priority of the processes to the highest level for the execution of the block, if I remember correctly. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

>> My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? > > I don't think so. AFAIK interrupts are checked on message sends and on > backward jumps (because of inlined loops just like in your example). > > So context switch may happen on each send... Ah yes!! I missed this case. Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

On Mon, Mar 24, 2014 at 10:00 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 20 mars 2014 Ã 17:04, Eliot Miranda a Ã©crit : > > On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Hi Eliot, >> >> Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : >> >> Hi Christophe, >> >> On Mar 19, 2014, at 1:45 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >> >> Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : >> >> On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >>> Why arguments should be read only? >>> They are just temporary variables with an initial value. >>> >> >> Read the blue book. It was a decision of the language designers to >> forbid assignment to arguments to allow debugging. The assignment to block >> arguments is a side-effect of the old BlockContext implementation of blocks >> where block arguments were mapped onto temporary variables of the home >> context. It is an anachronism and should be forbidden also. >> >> >> Thank you for the explanation. >> I'm just curious why it is so difficult to implement a debugger if >> arguments are assignable? >> If you need to restart the execution of a method, and so you need to get >> the initial value of the argument, I understand you cannot find the value >> anymore in the method context but it is available in the caller context, no? >> As I never implemented a debugger, I cannot figure out the difficulties. >> >> >> the args are no longer available; they get moved from the caller context >> to the callee. If you think about stack frames then what happens is that >> the slots containing the outgoing arguments are used as the slots for the incoming >> arguments. So if arguments are assigned to they are indeed lost. >> >> >> ok, I understand. Thank you for the explanation. >> >> >> But look at how many methods in the system (or in any system). The >> proportion of methods/functions/procedures that could be written to assign >> their arguments is very small so the Smalltalk trade off is a good one. >> >> >> I agree we don't really loose something. You can always assign arguments >> to temporary variables and update temporary variables. My point was just: >> if possible, why don't do it? >> > > It's that tricky trade-off between value and cost. Is it worth it? Does > doing it provide as much value as doing what it displaces (opportunity > cost). IMO it simply doesn't provide enough value, and there are different > priorities in the compiler. But if you disagree implement it your self and > then it'll be done. > > > It looks like "My point was just: if possible, why don't do it?" was > misunderstood. > I wanted to say: if available for free (no work needed, why forbid it?). > You gave a very good reason and I also think that the cost does not worth > the value. :) > Agreed. Good discussion. -- best, Eliot

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

Hi, On 24/03/14 17:56, Alexandre Bergel wrote: > Hi! > > Threads in Pharo have always been mysterious for me. > If I doit the following: [ true ] whileTrue > Can other thread interrupt this? > > Say in other words, can the following piece of code may suffer from a concurrent problem in Pharo > anOrderedCollection add: 42 > > My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? I don't think so. AFAIK interrupts are checked on message sends and on backward jumps (because of inlined loops just like in your example). So context switch may happen on each send... Jan > > What is the current status of this? > > Thanks to you all > Alexandre >

March 24, 2014

threading in Pharo

by Alexandre Bergel

Hi! Threads in Pharo have always been mysterious for me. If I doit the following: [ true ] whileTrue Can other thread interrupt this? Say in other words, can the following piece of code may suffer from a concurrent problem in Pharo anOrderedCollection add: 42 My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? What is the current status of this? Thanks to you all Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Christophe Demarey

Hi Eliot, Le 20 mars 2014 Ã 17:04, Eliot Miranda a Ã©crit : > On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : > >> Hi Christophe, >> >> On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >>> >>> Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : >>> >>>> On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >>>> Why arguments should be read only? >>>> They are just temporary variables with an initial value. >>>> >>>> Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also. >>> >>> Thank you for the explanation. >>> I'm just curious why it is so difficult to implement a debugger if arguments are assignable? >>> If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? >>> As I never implemented a debugger, I cannot figure out the difficulties. >> >> the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost. > > ok, I understand. Thank you for the explanation. > > >> But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one. > > I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it? > > It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done. It looks like "My point was just: if possible, why don't do it?" was misunderstood. I wanted to say: if available for free (no work needed, why forbid it?). You gave a very good reason and I also think that the cost does not worth the value. :) Cheers, Christophe.

March 24, 2014

Re: [Pharo-dev] new website about Artefact

by phil＠highoctane.be

+3 On Mon, Mar 24, 2014 at 3:53 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > 2014-03-24 14:40 GMT+00:00 olivier <olivier.auverlot(a)gmail.com>: > >> Hi, >> >> A website is now available about Artefact. Documentation and useful >> informations are grouped to help you to produce many and beautiful PDF >> documents with Pharo. >> >> https://sites.google.com/site/artefactpdf/ > > > I am of the opinion that any documentation that includes unicorns is an > automatic +1. > So, +2! > > Cheers, > Sergi >

March 24, 2014