home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / mswindo / programm / win32 / 949 < prev    next >
Encoding:
Text File  |  1992-09-13  |  2.2 KB  |  51 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!microsoft!hexnut!andrewgo
  3. From: andrewgo@microsoft.com (J. Andrew Goossen)
  4. Subject: Re: multiple threads per window?
  5. Message-ID: <1992Sep14.045409.14441@microsoft.com>
  6. Date: 14 Sep 92 04:54:09 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Sep13.012441.5140@microsoft.com>
  9. Lines: 40
  10.  
  11. In article <1992Sep13.012441.5140@microsoft.com> johnhall@microsoft.com (John Hall) writes:
  12. >In article bagwill@swe.ncsl.nist.gov (Bob &) writes:
  13. >| If I wanted to write an application which used multiple threads
  14. >| to draw a fractal in a window, which mechanisms should I use to
  15. >| avoid screwing up the drawing?
  16. >
  17. >That depends.  If they are drawing on different portions of the
  18. >screen (each thread takes a 1/4 slice of the window) then you
  19. >need do nothing.  If the drawing is order dependent to the
  20. >same pixel locations then take your pick:
  21. >   semaphores, mutex's, critical sections, event's
  22.  
  23. GDI objects are shareable between threads in a process; however,
  24. an object may be used by at most one thread at any one time.  
  25. For example, if two threads make GDI calls to the same DC
  26. at the same time, GDI will return an error to the second thread.
  27.  
  28. So it's up to the app to synchronize its use of GDI objects, using
  29. whatever of the many synchronization mechanisms that NT provides
  30. that they like.
  31.  
  32. In the above example, only if the app had split the screen into
  33. different DC's covering distinct sections of the window, with each 
  34. thread responsible for one DC, would the app not need to do 
  35. synchronization with respect to GDI.
  36.  
  37. A better design is to have one thread doing all the drawing to
  38. a DC, and the other threads doing the drawing computations.
  39. Another way is to have multiple threads simultaneously constructing
  40. a bitmap, and BitBlt the result when it's done.
  41.  
  42. It would be nice to allow threads to do true simultaneous drawing on 
  43. a device.  Unfortunately, at some level all device access must be
  44. serialized; things like hardware state and asynchronous pointer 
  45. movement requires this.
  46.  
  47. While GDI objects are shareable between threads in a process, they
  48. are not generally shareable between different processes.
  49.  
  50. andrewgo@microsoft.com        GDI person
  51.