[M3devel] pthread in cm3...

[Dragiša Durić]

I am running 4000, but it's not most important anyway...

Did you see that (Un)LockMutex semantics I've enabled so one can
overload methods invoked by LOCK .. DO?

dd

On Sat, 2007-05-19 at 16:00 -0400, Tony Hosking wrote:
> I just checked in a patch that is closer to your code, and that lets  
> me run 3200 threads on LINUXLIBC6 (I can't do 3500 because thread  
> creation fails for that many).
> 
> On Apr 25, 2007, at 12:35 PM, Dragiša Durić wrote:
> 
> > After implementing that workaround for result code 11 in that  
> > SIGSUSPEND
> > loop, every time during 1st or at most second pass (of 4000) it  
> > stucks.
> > Not same place every time, though... I think there are RCs in
> > LockHeap/SuspendAll logic.
> >
> > dd
> >
> > On Wed, 2007-04-25 at 09:51 -0400, Tony Hosking wrote:
> >> Yes, good thinking.  Tuning the threads systems is a good plan all
> >> round.
> >>
> >> On Apr 25, 2007, at 2:55 AM, Dragiša Durić wrote:
> >>
> >>> Just a random thought...
> >>>
> >>> I don't think my TestThreads is something special, but it's few  
> >>> thread
> >>> use patterns combined... And I've just had bright :) idea  
> >>> yesterday -
> >>> it's also decent benchmark for whole threading system... I think it
> >>> would be nice to test it with 10000 rounds, 4000 threads each (once
> >>> cm3
> >>> cvs-head is fixed) with PTHREAD and without PTHREAD. I will do
> >>> tests for
> >>> mine.
> >>>
> >>> I think these extra data structures and global locks in PTHREAD are
> >>> big
> >>> efficiency killers. Benchmark will show.
> >>>
> >>> dd
> >>>
> >>> On Mon, 2007-04-23 at 08:40 -0400, Tony Hosking wrote:
> >>>> I take all of your points seriously.  One option would be to offer
> >>>> your threads implementation as another build option for CM3.  I'm
> >>>> going to track down the bug I introduced recently and then we can
> >>>> consider how to move forward.
> >>>>
> >>>> On Apr 23, 2007, at 4:21 AM, Dragiša Durić wrote:
> >>>>
> >>>>> On Sun, 2007-04-22 at 15:59 -0400, Tony Hosking wrote:
> >>>>>> On Apr 22, 2007, at 10:47 AM, Dragiša Durić wrote:
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Have been skimming through source of PTHREAD code... And I think
> >>>>>>> job can
> >>>>>>> be done without so much relying on how-they-did-it-before, esp
> >>>>>>> with
> >>>>>>> regard to list of waiters and similar internal and global
> >>>>>>> structures.
> >>>>>>> Also, I see number of global locks and I am sure they are
> >>>>>>> congestion
> >>>>>>> generators every now and while, esp in heavy threading  
> >>>>>>> situations.
> >>>>>>>
> >>>>>>> Of course, there is number of approaches to this multi-thread
> >>>>>>> situations. Mine being one of very nonconservative use of
> >>>>>>> threads, I
> >>>>>>> think it is important to remain open to possibly very big
> >>>>>>> number of
> >>>>>>> threads running in single process - meaning scalability is  
> >>>>>>> one of
> >>>>>>> primary objections... As global locks don't do well with
> >>>>>>> scalability, I
> >>>>>>> don't like "cm" and similar global congestion points.
> >>>>>>
> >>>>>> Yes, there are tensions between a thin/absent veneer between
> >>>>>> language
> >>>>>> threads and system threads.  Most important are issues of
> >>>>>> preserving
> >>>>>> a reasonable memory model for programmers (see Hans Boehm's paper
> >>>>>> http://portal.acm.org/citation.cfm?doid=1065010.1065042).
> >>>>>
> >>>>> I know that paper, and being Modula-3 camp, I am - by definition -
> >>>>> agreed to no-library-approach-for-threads :).
> >>>>>
> >>>>>>  There are
> >>>>>> also questions of portability and debuggability.
> >>>>>
> >>>>>   Of course. That's why I am using only POSIX defined features,  
> >>>>> and
> >>>>> when
> >>>>> in doubt - ones used by Boehm in his famous GC :).
> >>>>>
> >>>>>> I agree that global
> >>>>>> locks are to be avoided where they cause known contention, but
> >>>>>> there
> >>>>>> are tradeoffs there too.
> >>>>>
> >>>>>   Global lock is bad, whatever reasons.
> >>>>>
> >>>>>> For large numbers of threads (as you appear
> >>>>>> to need) I think we would need to adopt some other implementation
> >>>>>> approach, possibly by multiplexing multiple lightweight user- 
> >>>>>> level
> >>>>>> threads on some smaller number of heavyweight system-level  
> >>>>>> threads,
> >>>>>> but then you run into scheduling and load-balancing problems.
> >>>>>
> >>>>>   I've argued this before... With O(1) process scheduling  
> >>>>> available
> >>>>> for
> >>>>> four years from Linux, and in that time surely from everyone
> >>>>> else... It
> >>>>> would be bigger problem to maintain scheduling for special "BIG"
> >>>>> cases
> >>>>> inside our support libraries than to rely on operating system.  
> >>>>> It's
> >>>>> good
> >>>>> that mainstream OS people recognized threads as Need, and it is
> >>>>> time now
> >>>>> for us to accept they did it well - AT LAST.
> >>>>>
> >>>>>   And, very important... I can't see what is heavyweight on system
> >>>>> which
> >>>>> does 10,000 context switches per second for 1500 threads with  
> >>>>> 2% CPU
> >>>>> load. And all this in 2004 on some 1.something GHz CPU. Threads  
> >>>>> WERE
> >>>>> heavyweight four years ago, and they are not, long since. Even
> >>>>> Windows
> >>>>> has lightweight kernel-space threads :).
> >>>>>
> >>>>>>
> >>>>>>> We talked about this at least once before, and I think I  
> >>>>>>> remember
> >>>>>>> you
> >>>>>>> insisted on more compatibility than can be read from SPwM3.  
> >>>>>>> Do you
> >>>>>>> think
> >>>>>>> best idea would be to integrate mine NPTL code into CM3 for
> >>>>>>> people to
> >>>>>>> trash and test, and let everyone select what is best for their
> >>>>>>> situation?
> >>>>>>
> >>>>>> What I wanted was a situation where programs would be able to run
> >>>>>> with the same tools (e.g., showheap, showthread) under both user-
> >>>>>> level and system threading.  This goal has been achieved with the
> >>>>>> current pthread-based implementation.
> >>>>>
> >>>>>   It is good reasoning, and it's one of reasons I did not suggest
> >>>>> replacement... I think mine version is less bloated and I know  
> >>>>> it's
> >>>>> very
> >>>>> good for long and stable process uptime we all expect from  
> >>>>> Modula-3
> >>>>> programs. But also, implied compatibilities outside of SPwM3 and
> >>>>> direct
> >>>>> demands from other parts of runtime were not on my list. These  
> >>>>> I've
> >>>>> respected, and it looks like these are good production time
> >>>>> criteria. As
> >>>>> opposed to excellent development time criteria you based yours on.
> >>>>>
> >>>>>> Moreover, I wanted something
> >>>>>> where variations in thread support from one system to another  
> >>>>>> could
> >>>>>> be exploited most easily (such as for systems where thread  
> >>>>>> suspend/
> >>>>>> resume is provided as a primitive).  Again, the current
> >>>>>> implementation achieves this, and runs with minimal target- 
> >>>>>> specific
> >>>>>> code on Darwin, Solaris, and Linux.  Ports to other targets
> >>>>>> should be
> >>>>>> relatively straightforward.
> >>>>>
> >>>>>   I've not ported mine outside of LINUXLIBC6, but as it's  
> >>>>> extremmely
> >>>>> POSIX, I see no problem.
> >>>>>
> >>>>>>
> >>>>>>> Problems I had with my pthread implementation were all related
> >>>>>>> to VM
> >>>>>>> hell of earlier GC implementation... After you did that piece
> >>>>>>> of art
> >>>>>>> with new approach to GC, I expect infinite uptimes from my
> >>>>>>> servers and
> >>>>>>> bots :). Big thanks for that!
> >>>>>>
> >>>>>> Any native threading implementation is going to have problems  
> >>>>>> with
> >>>>>> VM-
> >>>>>> based memory management.  I'm surprised to were able to get
> >>>>>> anything
> >>>>>> going with the VM-based GC.
> >>>>>
> >>>>>   Anything is pretty much - I have heavy multithreaded servers
> >>>>> running
> >>>>> literally for years,,, one of them is up since January of 2004, it
> >>>>> services few hundreds of connected users (and up to 1500  
> >>>>> threads) at
> >>>>> almost every moment and breaks only when system reboots :). All  
> >>>>> that
> >>>>> with heavy integration of various C libraries.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> dd
> >>>>>>> -- 
> >>>>>>> Dragiša Durić <dragisha at m3w.org>
> >>>>>>
> >>>>> -- 
> >>>>> Dragiša Durić <dragisha at m3w.org>
> >>>>
> >>> -- 
> >>> Dragiša Durić <dragisha at m3w.org>
> >>
> > -- 
> > Dragiša Durić <dragisha at m3w.org>
> 
-- 
Dragiša Durić <dragisha at m3w.org>