[C Linux Kernel] Completion opnieuw initen

[Enfer]

Hi,

Ik zit met een klein probleempje.. Ik ben bezig een device driver voor linux te schrijven voor een character device. Er zijn bepaalde lezers die input kunnen lezen zodra schrijvers iets wegschrijven in het (virtuele device).

Echter wil ik graag dat lezers alleen input gaan lezen als dat er ook echt is, vandaar dat ik een completion gebruik, zodat een schrijver de lezers "wakker" maakt als er werkt te doen is.

Zo gezegd zo gedaan, kom je op het volgende stukje uit: (includes en inits daargelaten)

C:

#include <linux/completion.h>

struct completion messagesAvailable; //voor lezers om te slapen als er geen berichten zijn

/File operation functies
int rn_open(struct inode *inode, struct file *filp){
    return 0;
}

ssize_t rn_read(struct file *filp, char __user *userBuff, size_t count, loff_t *offp){
    printk( KERN_INFO  "waiting for: %p\n", &messagesAvailable );
    wait_for_completion( &messagesAvailable);   

    copy_to_user( userBuff, "b", 1);
    (*offp) += 1;

    return 1;
}

ssize_t rn_write(struct file *filp, const char __user *userBuff, size_t count, loff_t *offp){
    complete_all( &messagesAvailable);
    printk( KERN_INFO  "inited complete for: %p\n", &messagesAvailable );
    return count;
}

//deze functies worden doorgelinked door gebruikers van het device
struct file_operations fops =
{
    .open = rn_open,
    .release = rn_release,
    .read = rn_read,
    .write = rn_write,
};

// Module ingeladen door de kernel
static int hello_init(void)
{
    int result;

    printk( KERN_ALERT "Kernelmodule completion: init_module() \n" );

    init_completion(&messagesAvailable);

    result  = register_chrdev(0, "completion", &fops);

    if( result < 0) {
        printk(KERN_WARNING "Error creating device\n");
        return result;
    }
    
    device = result;

    return 0;
}

Een schrijver maakt nu alle lezers wakker als er iets geschreven wordt. Echter vervolgens gaat een lezer weer iets lezen, maar wacht hij niet meer op de completion.

Nu ben ik er al achtergekomen dat dit komt omdat je de completion opnieuw moet initialiseren, echter zit daar ook mijn probleem.
Zodra ik de completion opnieuw initialiseer nadat de schrijver een complete_all() gedaan heeft(zo dus):

C:

complete_all( &messagesAvailable);
init_completion( &messagesAvailable );

krijgen mijn lezers niet meer het bericht dat ze verder mogen lezen.

Ik heb een beetje lopen zoeken op internet, maar er zijn maar weinig cases waar ik complete_all echt gebruikt zie worden, terwijl dit mij op deze plek wel de oplossing lijkt.

Kunnen jullie me vertellen waar/hoe ik mijn completion opnieuw moet initen, of dat ik toch maar beter een ander concurrency-hulpmiddel kan gebruiken?

[ Voor 11% gewijzigd door Enfer op 10-08-2010 17:51 ]

[Elijan9]

Dit klinkt mij meer alsof je blocking IO opnieuw wilt uitvinden, of mis ik iets?
Verder moet je misschien nog voorkomen dat de lezers al opnieuw in rn_read komen voordat de rn_write klaar is met complete_all, maar misschien is dat al wel geregeld via complete_all?

[Enfer]

Jup, het voorbeeld is natuurlijk vereenvoudigd maar het principe van completion is:
als je wait doet ga je wachten totdat je een signal krijgt (complete of complete_all), bij een complete maakt de schrijver 1 iemand wakker, bij een complete_all maakt de schrijver alle wachtenden wakker..

Wat betreft blocking IO, de bedoeling is dat als er een schrijver een bericht stuurt, dat alle wachtenden (0...N) wakker gemaakt worden. Dat kan nu 1x, maar na de complete_all is die completion onbruikbaar, en init_completion aanroepen reset alles waardoor de wachters uberhaupt nooit het signal van complete_all binnenkrijgen..

[Sappie]

Is het niet zo dat er een verschil bestaat tussen init_completion en INIT_COMPLETION? Als ik me niet vergis dient de laatste gebruikt te worden om de completion te herinitialiseren.

De init_completion call doet volgens mij namelijk wat meer dan de upper-case variant; het reset ook de onderliggende waitqueue (wat dan weer een soort linked list is). Ik ken de onderliggende implementatie van een completion niet, maar kan me voorstellen dat op deze manier de threads die wachten op completion niet meer ge-complete worden.

[Soultaker]

Een completion is bedoelt als one time event. Een beetje als een condition variable die niet gereset wordt na het waiten. Als je 'm meer dan eens initialiseert ben je verkeerd bezig, zeker als je dat doet terwijl er nog readers op aan het wachten zijn.

Ik denk dat je hier dus beter een ander soort synchronisatieprimitieve kunt gebruiken. Als elke schrijfctie correspondeert met precies één leesactie, dan kun je een semaphore gebruiken. Als na elke schrijfactie alle readers iets mogen lezen, is een condition variable (wait_event()/wake_up_all()) een betere optie.

In elk geval is een completion in dit geval de verkeerde datastructuur voor wat je wil bereiken.

[Enfer]

Sappie schreef op woensdag 11 augustus 2010 @ 19:17:
Is het niet zo dat er een verschil bestaat tussen init_completion en INIT_COMPLETION? Als ik me niet vergis dient de laatste gebruikt te worden om de completion te herinitialiseren.

De init_completion call doet volgens mij namelijk wat meer dan de upper-case variant; het reset ook de onderliggende waitqueue (wat dan weer een soort linked list is). Ik ken de onderliggende implementatie van een completion niet, maar kan me voorstellen dat op deze manier de threads die wachten op completion niet meer ge-complete worden.

Klopt, echter heb ik beide varianten geprobeerd, maar bij beide varianten blijft het probleem bestaan. INIT_blabla zet idd van een completion de "done" var weer op 0, terwijl bij init_completion inderdaad de waitqueue (oid) gereset hebt, dat klopt

Soultaker schreef op woensdag 11 augustus 2010 @ 20:20:
Een completion is bedoelt als one time event. Een beetje als een condition variable die niet gereset wordt na het waiten. Als je 'm meer dan eens initialiseert ben je verkeerd bezig, zeker als je dat doet terwijl er nog readers op aan het wachten zijn.

Ik denk dat je hier dus beter een ander soort synchronisatieprimitieve kunt gebruiken. Als elke schrijfctie correspondeert met precies één leesactie, dan kun je een semaphore gebruiken. Als na elke schrijfactie alle readers iets mogen lezen, is een condition variable (wait_event()/wake_up_all()) een betere optie.

In elk geval is een completion in dit geval de verkeerde datastructuur voor wat je wil bereiken.

Thanks, ik zal direct even kijken naar de condition_variabele met wait e.d, daar kan ik wat mee

Echter over je middelste opmerking, na een schrijfactie precies 1 leesactie, is het dan niet veiliger om een completion te gebruiken met "gewoon" complete? Van een completion ben je er zeker dat het FIFO is, van semaphore weet ik dat zo niet. Zo verklein je de kans op starvation?

[ Voor 27% gewijzigd door Enfer op 12-08-2010 11:06 ]

[H!GHGuY]

Soultaker schreef op woensdag 11 augustus 2010 @ 20:20:
Een completion is bedoelt als one time event. Een beetje als een condition variable die niet gereset wordt na het waiten. Als je 'm meer dan eens initialiseert ben je verkeerd bezig, zeker als je dat doet terwijl er nog readers op aan het wachten zijn.

Ik denk dat je hier dus beter een ander soort synchronisatieprimitieve kunt gebruiken. Als elke schrijfctie correspondeert met precies één leesactie, dan kun je een semaphore gebruiken. Als na elke schrijfactie alle readers iets mogen lezen, is een condition variable (wait_event()/wake_up_all()) een betere optie.

In elk geval is een completion in dit geval de verkeerde datastructuur voor wat je wil bereiken.

Als ik me niet vergis worden semaphores in kernel land afgeraden. Als ik me niet vergis staan ze zelfs op de lijst van gewenste removals... Veel kernel developers raden aan om mutexes te gebruiken ipv semaphoren.

Maar wait_event() en wake_up_all() is inderdaad de correcte interface om te gebruiken voor dit soort dingen.

[Enfer]

H!GHGuY schreef op vrijdag 13 augustus 2010 @ 12:58:
[...]


Als ik me niet vergis worden semaphores in kernel land afgeraden. Als ik me niet vergis staan ze zelfs op de lijst van gewenste removals... Veel kernel developers raden aan om mutexes te gebruiken ipv semaphoren.

Maar wait_event() en wake_up_all() is inderdaad de correcte interface om te gebruiken voor dit soort dingen.

Ermm, is een mutex niet gewoon een semaphore met size 1? Volgens mij wordt een mutex gedeclareerd als:

C:

struct semaphore test;

En geinit met

C:

DECLARE_MUTEX(test);

[H!GHGuY]

Kijk maar even in kernel/semaphore.c en kernel/mutex.c.

De implementaties verschillen wel degelijk en zijn zelfs niet in termen van elkaar geimplementeerd.

Bovendien is een binaire semaphoor en een mutex niet hetzelfde. Een mutex heeft een owner-thread, waarbij lock en unlock door dezelfde thread moet gebeuren, terwijl dit bij een semaphoor niet zo is.

definieren gebeurt trouwens met

C:

DEFINE_MUTEX(mutexname);
// of
DECLARE_MUTEX(mutexname);
void some_init(void)
{
  mutex_init(mutexname);
}

[ Voor 94% gewijzigd door H!GHGuY op 13-08-2010 17:39 ]

[farlane]

Raar, ook ik meende gezien te hebben ( in driver code ) dat de mutex functies deprecated waren en in semaphore termen werden geimplementeerd.

Als ik het goed begrijp moet dat in een single threaded omgeving dan ook mogelijk zijn?

[H!GHGuY]

farlane schreef op vrijdag 13 augustus 2010 @ 23:04:
Raar, ook ik meende gezien te hebben ( in driver code ) dat de mutex functies deprecated waren en in semaphore termen werden geimplementeerd.

Als ik het goed begrijp moet dat in een single threaded omgeving dan ook mogelijk zijn?

In single-threaded heb je helemaal niets nodig... (Tenzij misschien wat memory barriers op architecturen met memory re-ordering).

Mutex zal zeker niet deprecated worden, gezien de real-time patches en co. Mocht je me zo'n driver kunnen tonen, please do so

[farlane]

H!GHGuY schreef op zaterdag 14 augustus 2010 @ 11:45:
In single-threaded heb je helemaal niets nodig... (Tenzij misschien wat memory barriers op architecturen met memory re-ordering).

Ugh ... volgende keer zal ik m'n brein weer aanzetten

Mutex zal zeker niet deprecated worden, gezien de real-time patches en co. Mocht je me zo'n driver kunnen tonen, please do so

Zoekende

[farlane]

farlane schreef op zondag 15 augustus 2010 @ 00:12:
Zoekende

Beter laat dan nooit : de situatie was iets anders ben ik nu achter : init_MUTEX was een macro om sem_init( .., 1 ), maar die macro werd gedeprecated omdat er ook een 'echte' mutex is.

Zie ook bv hier : http://www.cs.fsu.edu/~ba...ude/linux/semaphore.h#L39