Hi! > -----Ursprüngliche Nachricht----- > Von: Phil Endecott [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 03. Jänner 2007 00:13 > An: Unger Richard > Cc: [email protected] > Betreff: Re: AW: [directfb-users] Multi-threaded directfb apps > > Unger Richard wrote: > >> Can anyone offer any advice about the requirements for > multi-threaded > >> DirectFB applications? > >> > >> I.e., if two threads both need to access the directfb system (to > >> create surfaces, decode JPEGs, blit to the screen etc), > does directfb > >> do the necessary locking, or must the application do this? > If it's > >> the application's responsibility, what operations cannot be > >> concurrent? > > > If accessing the same DFB structures from multiple threads > of the same process, my guess is that you will have to > synchronize everything quite carefully yourself. > > One exception should be the DFBSurfaces, and drawing to > them. By using the DFBSurface->Lock() function you should be > able to synchronize the actual drawing operations. > > Thanks Richard. > > So if I have two threads, each with their own private > surfaces, do they need to call Lock() before writing? Or is > Lock() only needed if that particular surface might be > accessed by more than one thread? >
These are excellent questions that you ask, and unfortunately I don't know the definitive answers. There just does not seem to be much documentation on DFB ;) - in the end I learn by reading code - looking at the examples. >From the examples my guess would be the following: (but it is only a guess) * If your app is single threaded, locking is optional. None of the "simple" examples ever include any locking code. * For a multi-threaded app, you have to do your own locking. Locking the Surface is necessary when you are busy drawing to it, since this might take some time, and anyway occurs "outside the DFB Core", in your own code. So DFB needs to know that other threads (processes in the multi-application case) cannot draw at the moment. As for the other structures, (eg SetSurfaceCapabilities or something like that), I think you need to use your own mutexes to protect these against concurrent access by your own threads. See the following post from the mailing list which I dug up: http://www.directfb.org/index.php/mailinglists/directfb-dev/2004/06-2004/msg00069.html That kind of confirms my suspicions. > Are the surfaces' Color, DrawingFlags, BlittingFlags etc. > private to the surface? Do I need to Lock() before changing them? > I think you need to use your own Mutexes. AFAIK Lock() is only for the surface buffer. > Do I need to lock around calls to the shared DirectFB object, > e.g. to CreateImageProvider, CreateSurface, and so on? > My guess would be no, since internally DFB must be using fusion to keep things clean in the multi-application case. But I don't really know. To be safe, it might be better to use mutexes. Eg: CreateWindow must modify the "Window List" -> what if another thread is Flipping() it's window surface, resulting in a redraw of the window stack. Is the WindowList internally synchronized against such concurrent access? I don't know... > (Does directfb do any locking at all for me? Are the > DirectFB functions reentrant?) > Yes, DirectFB completely handles the multi-application case, although this does not really help you. DirectFB also handles image drawing (and even movies!) through its Image- and VideoProviders, asynchronously. DirectFB handles input for you, asynchronously. In other words it looks to me like DFB tries to make it easy for you to work Single-Threaded... Try posting the question to the dev list as well, that's where most of the knowledgeable DFB "heavyweights" seem to hang out. It's a good question, and one that should be added to the FAQ in the Wiki if you can get an authorative answer... Regards from Vienna, Richard Unger > Cheers, > > Phil. > > > > > _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
